gedit handles opening big files badly

[Sebastian Breier]

Binary package hint: gedit

Opening big text files (400 MB, 750 MB) in gedit is bad
- from a usability standpoint
  -> There's no progress bar or cancel button for the action, and the load takes a long time.
- from a system standpoint:
  -> In earlier versions, gedit would take so much memory until the system swapped all other applications to disk, and the system became unusable.
  -> Since Ubuntu 9.04 Beta, gedit crashes without a GUI message, but the message "failed to allocate <X> bytes" in the console.

Original description:
I just opened a 400 MB text file (mbox mail file) in gedit, and it my system has now been unresponsive for minutes. Other editors can open large files without a problem. Also, there's no progress bar or cancel button that would make it easy to see how long gedit is loading the file or to cancel the load.

[Pedro Villavicencio (pedro)]

Thanks for your report.

[Volodya (volodya)]

Memory useage is also more than it should be. I have opened a 5 MiB file and memory used is 24.7 MiB and rising.

[Sebastian Breier (tomcat42)]

I just tried the same in 9.04 Beta, and gedit crashed without a warning.
Starting gedit from the console, I get an allocation error.

[badawi (danielbadawi)]

same problem here
freeze with a text file with only 2MB.

The content of the file is a single line... with 2MB

[Marat Dyatko (marat-dyatko)]

Same problem
Sometimes me can help switching off a syntax highlighting

[Denis Koryavov (dkoryavov)]

I have the same problem, and I have found one interesting detail: Gedit works fine if the file contains relatively short lines. In this mode, Gedit can open very large files (more than 100 MB). If the lines are long, Gedit freezes (and sometimes crashes) on a 4 MB file. Option "word wrap" no significant impact on productivity.

Ubuntu 9.10.

[Alex Solanos (hakermania)]

I have the same problem. Even if I open a file sized 15 MB and scroll down quickly, Gedit crashed without any message.

[tjombka (m-michalczyk)]

The same problem with 4MB files.

[Narcis Garcia (narcisgarcia)]

I've open a 54MiB .sql file with gedit 2.30.4 (Ubuntu 11.04) and no problem. There is now a progress bar.

But there are some lines with near 300000 columns where the editor doesn't scroll text when the user walks with the keyboard cursor to the first or the last characters, and with "text wrapping" it refreshes poorly the work area when Search&Replace.

[Mike Fairbank (michael-fairbank)]

I have noticed this bug. I have a 5MB document with very long lines. Each line is approximately a million characters wide.

If you view it with word wrap OFF then the computer becomes very unresponsive. Scrolling the scrollbars particularly hangs the computer for a long time.

I'm on gedit 2.30.4. I'm using a 15GB machine so manipulating a 5MB text file should not be causing it to sweat.

I've attached an example file that causes the problem. Make sure you view it with text wrap off.

[David Mignani (david-mignani)]

I experimented a similar problem.
I use gedit to inspect huge SQL dump files (40-50 MB).
With Ubuntu 10.04 (gedit v. 2.30.3, if I rebember well) I got such files opened in few seconds, while with Ubuntu 12.04 (and gedit v. 3.4.1) the operation is terribly slow and impacts the whole system speed and responsiveness.

[NoBugs! (luke32j)]

Same here,with 13.10, on a relatively small 23MB file - very high cpu, though it is using <100MB of memory! With 6gb RAM you would think it would be able to open it. Ironically, the full IDE MonoDevelop opens the file in a second.

[tr33m4n (tr33m4n)]

Same on 13.10 64. I've not experienced such performance loss when opening large files in say Kate, Geany etc

[svecpetr (svecpetr-svecpetr)]

Same on 13.10 and big files begin on 1 MB of XML data ... (quad core and 16 GB of free memory is not enought to open 1 MB file)

[uwe (maabdulhaq)]

really bad performance on 14.04 , opening a 1.9MB file, takes a long time and returns wait or quit message a few times while loading

[Teo (teo1978)]

It's much worse than described. It's not just that you don't (and should) see a progress bar, that the whole UI blocks (and shouldn't) and that you don't get a warning when the file actually can't be properly handled.

It's also that handling of big files is ridiculously inefficient.

A file as small as 30MB hangs gedit, takes ages to load, and renders the UI unresponsive every once in a while when trying to scroll it.
I can open the very same file in VIM seamlessly in a fraction of a second and navigate through it. And vim does syntax highlight too.

[Teo (teo1978)]

I mean (just in case i wasn't clear), the problem is not only in bad handling of truly unmanageable files (which should fail gently), but also in a tremendous inefficiency that makes it impossible to handle files that could perfectly be handled.

[Jay-qu (newjay)]

I have this issue on gedit 3.10.4 and ubuntu 15.04.. it is a little ridiculous that gedit totally chokes on an 8mb file when I have 8Gb of RAM on a modern computer.

[Vincent Gerris (vgerris)]

I have the exact same problem. From a usability point of view, this editor is practically useless for big files and I wonder why it is the default editor?
The bug should either be fixed or another editor should be set as default in my opinion.
Vim opens the same file in not even a second and LibreOffice includes weird encoding and still is many times faster.

the file I use is 20 Mb, my system has 16 gb of memory and gedit really chokes in it.
Takes MINUTES to open it.
Sublime text takes about a second. too.

[David Lévêsque (photon0)]

It’s been nearly a decade now and this is still an issue… Micro$oft engineers must be making jokes about this. Editing a 5MB text file should not be a problem.
Seriously though, my intuition is that it can be narrowed down to the system displaying Unicode characters as their double byte code in one character space. Maybe, the approach should be to use one single generic “U” in a small rectangle as the only graphical representation of unknown characters. I doubt it is of vital importance to display the exact Unicode value of special characters. Users who need this kind of information probably use specialize tools already.
As for me, I gave up. Now I use Bless Hex Editor when it comes to text files containing blobs and such.

As an example I attached a mysqldump file containing a single row insert with about 3MB blob data. Such a file is impossible to edit using gedit 3.18.3 in Ubuntu 16.04 with a 6 core CPU, 12GB RAM and a SSD drive. gedit just hogs an entire core and slowly eats up RAM (250MB after 5 minutes of processing and it keeps on rising).

[Julian Alarcon (julian-alarcon)]

I'm using right now Centos 7 with Gedit 3.14.3 (gedit-3.14.3-18.el7.x86_64).

This has a progress bar (part of the bug description), but after it finish is also frozen.

[PabloRQ (pablo-romeroquinteros)]

Same issue on Ubuntu 16.10.

REALLY??? 10 years and it's still happening this issue??!

[kaptoxic (kaptoxic)]

This behavior is quite annoying, especially since in some cases the system accidentally opens other formats (e.g. PDF) in gedit, which just freezes the app, and, if any other tabs are open, information from all the buffers is just lost.

[madbiologist (me-again)]

This needs to be fixed. In the meantime, try using nano. Unfortunately nano doesn't have syntax highlighting.

[Simon May (socob)]

“Unfortunately nano doesn't have syntax highlighting.”

nano does have syntax highlighting!
https://wiki.archlinux.org/index.php/nano#Syntax_highlighting

[Vincent Gerris (vgerris)]

Nano is not a gui desktop editor. Besides that vim is superior to nano in
my opinion. A viable alternative would be an open source editor like Atom,
but it can be useful to have a lightweight simple editor that doesn't blow
up with a big file and is installed by default.

On Wed, Jan 23, 2019, 21:45 madbiologist <<email address hidden> wrote:

> This needs to be fixed. In the meantime, try using nano. Unfortunately
> nano doesn't have syntax highlighting.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/156201
>
> Title:
> gedit handles opening big files badly
>
> Status in gedit:
> Confirmed
> Status in gedit package in Ubuntu:
> Triaged
>
> Bug description:
> Binary package hint: gedit
>
> Opening big text files (400 MB, 750 MB) in gedit is bad
> - from a usability standpoint
> -> There's no progress bar or cancel button for the action, and the
> load takes a long time.
> - from a system standpoint:
> -> In earlier versions, gedit would take so much memory until the
> system swapped all other applications to disk, and the system became
> unusable.
> -> Since Ubuntu 9.04 Beta, gedit crashes without a GUI message, but
> the message "failed to allocate <X> bytes" in the console.
>
>
>
> Original description:
> I just opened a 400 MB text file (mbox mail file) in gedit, and it my
> system has now been unresponsive for minutes. Other editors can open large
> files without a problem. Also, there's no progress bar or cancel button
> that would make it easy to see how long gedit is loading the file or to
> cancel the load.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gedit/+bug/156201/+subscriptions
>