Ich hatte seit einer Weile unter Ubuntu das Problem dass das Öffnen von vielen, leeren oder kleinen Textdateien mit gedit relativ lange dauerte und die CPU Last in die Höhe schoss. Da die Last parallel auch bei anderen Anwendungen wie evince und openoffice in die Höhe ging, war mir früh klar dass es vermutlich nicht an gedit selbst sondern an einer gemeinsam genutzen Systemkomponenten liegen muss. Da ist Zeitgeist wegen ähnlichen Problemen wieder deinstalliert hatte, verdächtigte ich die offensichtlichste Funktion “Zuletzt geöffnete Dokumente”. Hier notieren alle genannten Anwendungen beim Öffnen einer Datei diesen Vorgang in die Dateiliste unter ~/.recently-used.xbel und wenn gedit 100 Dateien auf einmal öffnen, bedeutet dass im Zweifelsfall 100 einzelne Schreibvorgänge die Liste. Ich weiß zwar nicht warum, aber scheinbar bemerken die genannten Programmen jedes Update der Dateiliste. Damit ist klar warum das Öffnen von vielen kleinen Dateien so einen Aufwand macht.
Hier schon einmal die Lösung nach mehreren Lösungsversuchen: gedit statt pluma
Genau genommen nutze ich Mate 1.4, pluma, atril und libreoffice – keine Ahnung ob dass ein Unterschied macht.
Als Workaround habe ich die “Zuletzt geöffnete Dokumente” Funktion deaktiviert. Die einfachste Lösung fand ich hier es ist eigentlch kein Deaktivieren, sondern eher ein Lahmlegen. Ich habe mich für Alternative 3 entschieden:
Letzte Möglichkeit ist das Löschen der Datei und Erstellen eines gleichnamigen Verzeichnisses:
Code:
rm ~/.recently-used.xbel
mkdir ~/.recently-used.xbel
Interessanterweise funktioniert die “Zuletzt geöffnete Dokumente” Liste immer noch, aber gedit öffnen die Dateien nun etwas schneller.
Eine elegantere Alternative:
Hi there. An even easier way is to make $HOME/.local/share/recently-used.xbel immutable like this (as root):
CODE: SELECT ALL
chattr +i /home/YOURUSER/.local/share/recently-used.xbel
Ah, hier gibt es eine Erklärung: Platform-dependent performance issues when selecting a large number of files with gtk.FileChooserDialog:
The slowdown is due to the fact that the gtk.FileChooser widget automatically puts all the files selected into the recently used file list (gtk.RecentManager.add_item()).
[...]
Since there is no method to add multiple files to the RecentManager, they are added one at a time.
[...]
The problem is exacerbated by the fact that recently-used.xbel is able to grow without limit. So if you have 5000 items in recently-used.xbel, and you’re selecting 200 files with a gtk.FileChooser, you’ll get (sum from n=1 to 200) (5000 + n) ~ 1 million system time calls for each gtk app running.
Und dort gibt es auch ein Hinsweis warum ich das Problem früher noch nicht hatte und warum es doch ein Unterschied macht ob ich pluma (gtk2) oder gedit (gtk3) nutze:
Relevant bug report on the fact that gtk.RecentManager.add_item() is slow, looks like it might have been fixed in gtk3 but not gtk2. bugzilla.gnome.org/show_bug.cgi?id=616997 – Chris Billington Feb 15 at 1:22
Interessant, das ist der erste Vorteil den GNOME 3 hat – es nutzt gtk3 und darum nutzt auch gedit gtk3. MATE ist da noch nicht so weit: The developers plan to port MATE to GTK+ 3,[5] though another plan to stay with GTK+ 2 has also been expressed.[6]
Wie gut dass unter Linux quasi alles mit allem kompatibel ist und ich pluma einfach durch gedit erstzen kann, falls mein Workaround doch nicht funtkioniert.
