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.

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.

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.

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.

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.

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.

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.