A few days ago, Claudio wrote about the time Eog spent saving the filename of a recenlty used image into ~/.recently-used.xbel. The reason: ~/.recently-used.xbel was too big. If I remember correctly, the FileChooser used to have a similar issue in the past.
Going down from 5.8 MiB to 1.8 MiB, through deleting all those items whose files does not exists, seems to be a good improvement. I wanted to go a bit further and I wondered ¿How many recent files does an application really need? (sorry, not that further :-) I do not think more than 10 per application, but let me know if I am wrong.
I wrote my own version of Claudio’s program with that matter in mind. And my ~/.recently-used.xbel file went down from 1.2 MiB to 54 KiB. Before to go to the script, let me show you the numbers I got in a computer with less than two month of non intensive use:
gpoo@pendragon:~$ python clean-recently-used.py -v
Summary:
1 Reproductor de películas Totem
1 Glade
4 GNU Image Manipulation Program
4 Navegador web
9 Visor de documentos Evince
9 File Roller
14 Web Browser
15 Gnumeric Spreadsheet
26 gedit
34 Administrador de archivos
36 Evince Document Viewer
52 Totem Movie Player
292 File Manager
1151 Eye of GNOME Image Viewer
Whenever I run Eog, it always shows me only the last 5 files I opened before. Why does it need 1146 extra items stored?
Nevermind. The script I wrote is simple. It deletes those files that does not exists (the same strategy used by Claudio’s program), but it also deletes those files that are not so recently used, and I got the following numbers:
gpoo@pendragon:~$ python clean-recently-used.py -v
Summary:
1 Glade
3 GNU Image Manipulation Program
4 Navegador web
8 File Roller
9 Visor de documentos Evince
10 Totem Movie Player
10 Eye of GNOME Image Viewer
10 Web Browser
10 Gnumeric Spreadsheet
12 Evince Document Viewer
13 Administrador de archivos
14 gedit
41 File Manager
Now you can put the script to be executed when you start your session or you can program it as a cron task.
If you are only interested in getting a summary, you can run the script just using the option -v.
instead of using the session start, this should be invoked with the session ending, to avoid cluttering up an already slow start up sequence.
also, see my blog for what is missing from gtk+ and why.
At least in 2.22.x Gnome (i.e. in 2.x.y gtk+) you can enter it by GtkFileChooserDialog.
Well ideally the old Recent items would overly into a History list rather than falling into a useless limbo.
I also have been looking into this and the issue isn’t really with eog its with ‘gtk recent manager’, and interestingly I blogged about this only yesterday read more here: http://blog.buttermountain.co.uk/2008/03/31/high-cpu-usage-from-eog-gnome-panel-blame-gtks-recent-manager/
It really needs to be fixed.
I proposed an automatic cleaner at http://bugzilla.gnome.org/show_bug.cgi?id=524896. It limits the items by age, imposes a maximum number per mime type, and deletes non-existent ones.
You’ll save a few lines by using defaultdict
Cleaning up after applications who are putting entries in this history file is a really bad way of doing it. This would not address the root cause in any way, it would merely hide the problem and create extra complexity.
I believe that the following should be done:
1. Applications should not be responsible for cleaning up after them selves, there should be a default limit (say 25 entries per app) which can be extended if needs be by the application. Effectively if we add a new entry and we have hit our limit the oldest entry gets pushed off the end of the list.
2. do not call the time() system call for every entry in the recently-used file when sorting it, this is really inefficient and I’m fairly certain this is the slowdown people are experiencing.
In short: redesign the recent-manager not create a new bit of code to look after the mess it creates!
Ian, as was pointed by Emmanuel and Alan, applications like Gimmie couldn’t access the historical data if this is not available.
What about having 2 recently-used files? I mean, recently-used.xbel and recently-used-history.xbel. Both of them below the same GtkRecentManager API. The limit may be hardcoded (25 as you say), good enough for a quick search by the every day use but not losing the historical data.
Björn,
I wasn’t aware about defaultdict. Good to know it, thanks :-)
Ian,
You should look the patch and discussion given by Mike
(#524896)