How many recent files does an application really need?
A few days ago, Claudio wrote about the time Eog spent saving the filename of the recenly 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.
Passing from 5.8 MiB to 1.8 MiB, through deleting all those items whose files does not exists, seems a bit gain. I wanted to go a bit further and I wondered ¿How many recent files does an application really need? (sorry, not that futher :-) I do not think more than 10, but let me know if I am wrong.
I wrote my own version of Claudio’s program with considering that matter. And my ~/.recently-used.xbel file went from 1.2 MiB to 54 KiB. Before to go to the script, let me show 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
When I load Eog, it only show me the last 5 files I opened before. Why does it need 1146 extra items stored?
Nevermind. The script I wrote is simple. It delete the files that does not exists (the same strategy as Claudio’s program), but it also delete the 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 a cron task to do it.
You can play with the script using it just with -v, which will give you only a summary of use.
And it is slow when delete items (in seconds), but much better when it is controlled.
April 1st, 2008 at 04:31
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.
April 1st, 2008 at 04:43
At least in 2.22.x Gnome (i.e. in 2.x.y gtk+) you can enter it by GtkFileChooserDialog.
April 1st, 2008 at 05:12
Well ideally the old Recent items would overly into a History list rather than falling into a useless limbo.
April 1st, 2008 at 07:44
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.
April 1st, 2008 at 08:27
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.
April 1st, 2008 at 09:19
You’ll save a few lines by using defaultdict
April 1st, 2008 at 10:20
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!
April 1st, 2008 at 10:44
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.
April 1st, 2008 at 10:45
Björn,
I wasn’t aware about defaultdict. Good to know it, thanks :-)
April 1st, 2008 at 10:59
Ian,
You should look the patch and discussion given by Mike
(#524896)