Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Huge speed regression after having upgraded from Gedit 2.28 to 2.30 #3

ghost opened this Issue · 3 comments

1 participant



I was using the original trailsave plugin, with large text files (>1MB), without problem, but after having upgraded from Gedit 2.28.4 to 2.30.3, saving started taking more than five seconds. Deactivating the trailsave plugin makes Gedit save these files pretty much instant again. I tried to find possible updates to the plugin, saw it was not maintained anymore, found out about your version, installed it, and the problem is exactly the same (I like the new cursor position preservation option though, I won't miss having to re-enter spaces/tabs multiples times before I decide what to write next, saving my file each time by reflex, although it did feel like I was at least doing something ;)).

As I tend to save very often, it makes it very difficult to use. It catches my attention while I'm trying to think about what to write next (even more so because Gedit scrolls back a few lines, because of the progress bar display during saving, so I cannot even see what I was writing, if it was at the bottom of the window).

It starts getting visible with 300KB files. With 600KB files it already takes seconds.

I could try to save less, but I have had bad experiences with crashes and stuffs in the past, and I regularly write quite a lot in one go, so it could become risky loosing it. And it's too late to split these files for now ^_^;

I suppose this could easily be unbearable in itself, for even larger files like big log files (Gedit is already a bit slow with them :/), even if surely seldom edited manually.

Any idea if this could be improved?

In the worst case, would it be possible to include an option to not remove trailing whitespaces for files larger than xKB (300KB if static and by default if editable), and then add a new keyboard shortcut, like Ctrl+Alt+S (it does not seem to be taken), which people could use occasionally, to remove possible trailing whitespaces (and save, to avoid multiple behavior changes). There could be some nuances which I suppose would not cause performance problems, like still stripping white lines at the end of the file, and removing trailing whitespaces for the one hundred lines before and after the cursor (detailed in a tooltip or at least in the README). More bloat, though :)

Thanks in advance,



Hi Mathieu,

Thank you for your detailed report. I can see that this is a real issue and should be fixed. Algorithm-wise it is pretty clear that the end-of-line whitespace removal is slow on big files, because it has to check every single line in the file and the bigger the file, the more it has to check. The other options (empty lines at the end of the file and the don't strip whitespace left of the cursor) are not getting slower the bigger the file gets.

Unfortunately I currently don't see a lot of improvement in the algorithm without having a completely different approach - like only deleting the whitespace when hitting Ctrl+Alt+S or cleaning the file while editing, or whatever else. Your other idea (cleaning only a few 100 lines around the cursor does seem like an option, but I don't like that this might lead to files that have not all of the whitespace removed. It feels a bit wrong to me.

What disturbs me more is that you are saying, that it seems to be a problem only with Gedit 2.30.x (maybe only 2.30.3), If this proves to be true, this seems to be more of a bug with Gedit than with this plugin.

I'm going to investigate on this and keep you informed about the progress.




With Gedit 2.28.4, saving was pretty much instant, even with my large files. In fact, I just tested downgrading only Gedit to 2.28.4 (i.e., no GtkSourceView downgrade, notably), and with your extension activated and working properly, saving is instant again on my large files. Upgrading again to 2.30.3, and saving takes 1MB files takes >5s again.

I posted this report here, because I read there had been various important internal changes, notably related to GtkSourceView, in the past few major versions of Gedit, so maybe there was simply a new way to do what trailsave/whitespace-remover was doing in an optimized manner, while the older way became slower due to these changes, or something like this.

However, this may indeed just as well be some bug or new unoptimized bloat in Gedit (I noticed a few other things slowing down in Gedit with my large files -notably adding new lines or modifying/adding characters inside a line, instead of at the end (although deactivating all the plugins make it as fast as before again, so I'll have to check if another specific extension is causing problems)-, although nothing to the extent of trailsave/whitespace-remover).

[Edit: Note that activating only your extension, and no other, does not change anything, so it is not caused by the interaction with another extension].

[Edit2: The other extension slowing down editing is AutoComplete, from -another extension derived from BTW... I'll contact them later too]


Because of move to gedit 3, this issuie will be closed without further action.

Please fell free to open another issue if it still occurs in gedit 3.

@dinkel dinkel closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.