GNOME Bugzilla – Bug 362374
Unlimited growth of "~/.recently-used.xbel" causes performance issues
Last modified: 2007-07-19 20:25:57 UTC
Please describe the problem: The unlimited growth of the file "~/.recently-used.xbel" causes performance problems with gedit and other applications that access it. As the file grows the problems become more and more pronounced and deleting it they disappear completely. Steps to reproduce: 1. Make sure your "~/.recently-used.xbel" has grown to a reasonably big size (about 1mb) 2. Open an existing text file and position the cursor at the beginning of a line. 3. Press ctrl+s and immediately hold down the right arrow key to move the cursor along the line. Actual results: A short moment after the document is saved and the cursor is moving to the right it suddenly freezes for a moment and then continues to move. The duration of the freeze is directly related to the file "~/.recently-used.xbel" and in my worst case was over a second. Expected results: The handling of recently used files should be more efficient and there should be some limits as to how big this file can grow. In my case the filesize was approaching 2mb and I don't think it's necessary to know which file I opened in gedit two months ago even though I've opened hundreds of other files since then. The contents should be limited to the actual most recently used files only. Does this happen every time? yes Other information: This problem seems to occur even across application boundaries. When I double-click an mp3 file in nautilus and immediately switch to gedit I see the same problem even though it's not gedit modifying the file.
Thank you very much for the detailed bug report. The "~/.recently-used.xbel" file is used by gedit to store recent files but it is not a gedit specific file so the problem is not due to gedit ifself but to gtk+. Moving to gtk+.
the parser for the .recently-used.xbel file has been tested with files as big as 2/3 megs; a 1.5 MB file stores 3300+ links and takes less than half a second in warm cache state to parse it[1]. if it causes slowdowns I don't think it's due to the parser, but I'd like to see some profiling numbers myself before touching something that has already been profiled to the death. also, remember that the file is re-parsed if it has been changed. the size of the old recently used files storage file was limited to 500 entries; it was an arbitrary size, and I think 1000+ is a more useful number. but, in the end, a way to clear the old stuff might be needed. the GtkRecentManager API provides a purge method, but it'll clear everything from the list; probably better would be creating a filter on the list returned by the gtk_recent_manager_get_list() function and the call gtk_recent_manager_remove() on the matching entries. another interesting option might be a dialog to choose what to remove from a list, maybe inside the panel. +++ [1] http://log.emmanuelebassi.net/archives/2005/11/profiling-gmarkup-3/
Why exactly is "File Manager" clogging up the file in the first place? I deleted the file yesterday and a little bit more than 24 hours later there are already 174 File Manager entries in there again. I don't even know what they are good for as I haven't found a way to access them from Nautilus so it seems to be more of a design issue that application A can interfere with the performance of application B by filling up this file. I think there are three possible ways to remedy this: a) Manage the recently used files for each application separately so that app A cannot mess things up for app B. b) Manage them together but make the API enforce some ground rules. c) Move the management of the recently used files out of process so that it doesn't interfere with the running app. Personally I'd like to see option b with a per application default limit applied because I'm not sure why I would like to have 300 entries in there leave alone thousands.
Dennis, each time you open something via Nautilus a new entry will be created with the group "File Manager"; since entries are store per-URI you won't have duplicates. as for your suggestions: a) we would end up with 8a lot* of files with a lot of complications (duplicates, access time, merging, concurrent access, etc.), so it's a no-go; b) the API does not (and will not) enforce anything - because it's up the the user decide how many files should be retained/purged; we already went down that road and it wasn't useful for everyone. we can create system-wide policy on top of the API, but I will *not* add an artificial limit into GtkRecentManager because what looks reasonable to me doesn't to other users and vice-versa. c) as I said, I'd like to see numbers before operating such an intrusive change into the manager object. can you please try to replicate the slow-down under a sysprof session (http://live.gnome.org/Sysprof) and attach the profiling session dump to this bug report so I can see where the slow-down happens?
Created attachment 75106 [details] sysprof dump Here is the sysprof dump. >each time you open something via Nautilus a new entry will be created with >the group "File Manager"; since entries are store per-URI you won't have >duplicates. But what does it store this information for? As I mentioned I have not found a way to access this info nor do I have any use for it so it seems wasteful to store this in the first place. Since it does interfere with things I do care about though this is an "all pain no gain" scenario for me. Nautilus should not store this data unless there is a good reason for that and even then should limit the number of entries in some way.
thanks for the sysprof dump. (In reply to comment #5) > But what does it store this information for? to know exactly which application you used to open a file, in order to use it again the next time you launch the same file, instead of using the default MIME handler. example[1]: XML files are handled by mozilla using their MIME types, which is perfectly fine; however, if I want to open a XML file for editing with Gedit, and I select "Open with application" in Nautilus, I expect that each time I double-click on the very same file I can open it in Gedit too. this indeed works fine - *in Nautilus*; but if I want to open the same file from the recently used documents list it'll be opened by mozilla. hence, the change to store the application used to open a file. > As I mentioned I have not found a way to access this info nor do I have any > use for it so it seems wasteful to store this in the first place. it doesn't really matter if *you* don't use it (now): it's there to be used in case someone wants to, and it's there especially because users *expect* it to behave this way. > [nautilus] should limit the number of entries in some way. nautilus could expose the list of recently used documents using an extension or a special place, like the Trash or the CD burner; the panel could offer a menu item to show the complete list and mark documents as "sticky" (keep them even when clearing the whole list) or mark documents for removal. I had a recent-documents-applet in the works, some time ago, when the recentchooser API was still in libegg; I'll port it to the gtkrecent API and package it. +++ anyway, I'll have a look at the profiler run and see what I can get from it. [1] please, see: http://live.gnome.org/RecentFilesAndBookmarks
(In reply to comment #6) > thanks for the sysprof dump. > > (In reply to comment #5) > > > But what does it store this information for? > > to know exactly which application you used to open a file, in order to use it > again the next time you launch the same file, instead of using the default MIME > handler. > > example[1]: XML files are handled by mozilla using their MIME types, which is > perfectly fine; however, if I want to open a XML file for editing with Gedit, > and I select "Open with application" in Nautilus, I expect that each time I > double-click on the very same file I can open it in Gedit too. this indeed > works fine - *in Nautilus*; but if I want to open the same file from the > recently used documents list it'll be opened by mozilla. hence, the change to > store the application used to open a file. I just tried this and double clicking a XML file or selecting it from the recently used document list *always* uses the default application defined for that MIME type no matter what application I selected in "Open with application" before for that document. Is there a setting that controls this that might be disabled on my machine? (I'm running FC6 btw)
it means that the panel isn't calling the right program as stored by nautilus; I suggest you open a bug for the gnome-panel product about this. the panel should use the gtk_recent_info_last_application() function to get the last application that registered the document and then use it in gtk_recent_info_get_application_info() to retrieve the command line to call.
I would like to see the list pruned of old entries by something. Old would mean... 1. Files that no longer exist. 2. Files not accessed within a certain (configurable) time. The default could be something on the order of a month. There is a privacy aspect too. Just like Firefox has "Clear Private Data", so should gtk (or gnome). (For the record, I am seeing the same behaviour as in comment #7 on OpenSuSE 10.2)
yes, behaviour in comment #7 is really a FIXME in gnome-panel (I have been working on a patch for that, but it's not ready). as for pruning/managing the list, nautilus or gnome-panel can do that, being the users of the recent-files list that are "always-on". the API for managing the list is already inside GTK+: removing stuff is a user action, the GtkRecentManager cannot decide for you.
(In reply to comment #9) > I would like to see the list pruned of old entries by something. I don't think this is a real solution for the problem. Right now I have emptied the file and done a "chattr +i" so apps cannot write to it anymore. This "fixed" the performance issues for me. The real problem is that the file just gets to damn big and the main culprit here is nautilus adding every file that gets touched to it. I would like to use the recent file menus in the applications but I have absolutely no interest in the desktop remembering what file I clicked on in nautilus two weeks ago. That's what MIME types are for. The number of files that get added by apps like gnome-edit or abiword is much much smaller than what gets added by nautilus because people tend to work with a relatively small number of the same files whereas they tend to click on a lot of different ones in nautilus over time (mp3s, text files, archives, photos, etc.). Limiting nautilus would make most of the pain go away I think. An alternative would be to make the handling of the file more efficient. The reason why 1000 nautlius entries should slow down gnome-edit is still not clear to me.
marking ad duplicated of bug 439715 because the topic is the same, and the other bug has a patch for adding a configurable limit for the recently used files list. *** This bug has been marked as a duplicate of 439715 ***