After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 488507 - boundless growth of .recently-used.xbel file slows down applications
boundless growth of .recently-used.xbel file slows down applications
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Class: GtkRecent
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Emmanuele Bassi (:ebassi)
: 507673 512108 523252 524896 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-10-20 06:24 UTC by Behdad Esfahbod
Modified: 2008-04-15 22:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[PATCH] Clamp items by age (4.41 KB, patch)
2008-04-01 12:09 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review

Description Behdad Esfahbod 2007-10-20 06:24:45 UTC
With gedit-2.15.9-1.fc6, a friend of mine had this problem that saving in gedit caused 5 seconds of 100% cpu use.  I traced it a bit and gedit seems to call gtk_recent_info_get_modified() thousands of times...

Removing ~/.recently-used* "fixed" the problem.  I expect this to be fixed in more recent versions, but thought I report it still.
Comment 1 Paolo Borelli 2007-10-20 17:30:00 UTC
mmm... no idea really. we do not call gtk_recent_info_get_modified directly... maybe a bug in that version of gtk?
Comment 2 Behdad Esfahbod 2007-10-22 22:03:13 UTC
Well, it does in gedit-window.c:sort_recents_mru()...

That doesn't explain why lots of time() syscalls are made though, as that function uses cached info.  I'll grab the old .recently-used files and see what's going on.
Comment 3 Behdad Esfahbod 2007-10-30 22:18:54 UTC
The .recently-used.xbel in question has 4200 bookmark entries, mostly photos.
Comment 4 Paolo Borelli 2007-11-02 22:56:08 UTC
I am pretty sure it should not happen anymore with newer gedit releases (I thing 2.18 and above):


static gint
sort_recents_mru (GtkRecentInfo *a, GtkRecentInfo *b)
{
	return (gtk_recent_info_get_modified (a) < gtk_recent_info_get_modified (b));
}

...

static void
update_recent_files_menu (GeditWindow *window)
{
	...

	/* filter */
	for (l = items; l != NULL; l = l->next)
	{
		GtkRecentInfo *info = l->data;

		if (!gtk_recent_info_has_group (info, "gedit"))
			continue;

		filtered_items = g_list_prepend (filtered_items, info);
	}

	/* sort */
	filtered_items = g_list_sort (filtered_items,
				      (GCompareFunc) sort_recents_mru);


we now filter and then sort so the the images entry should get filtered out.
It would be great if you could test that recent file with a new version of gedit just to be sure.


Obviously I still think that the fact that .recent-files.xbel grows indefinately is a problem, but that's a generic gnome/gtk issue.
Comment 5 Behdad Esfahbod 2007-11-02 23:38:26 UTC
Still happening with gedit-2.18.2-1.fc7, but it's less noticeable as saving now happens asynchronously.

The calls seem to be from gtk+ itself as you first suggested.  Here is stacktrace showing where thousands of time() syscalls are coming from:

  • #0 time
    from /lib/libc.so.6
  • #1 build_recent_info
    at gtkrecentmanager.c line 1677
  • #2 gtk_recent_manager_get_items
    at gtkrecentmanager.c line 1311
  • #3 ??
  • #4 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #5 g_closure_invoke
    at gclosure.c line 490
  • #6 signal_emit_unlocked_R
    at gsignal.c line 2440
  • #7 g_signal_emit_valist
    at gsignal.c line 2199
  • #8 g_signal_emit
    at gsignal.c line 2243
  • #9 gtk_recent_manager_add_full
    at gtkrecentmanager.c line 1380
  • #10 _gedit_recent_add


May just be the unbounded growth...  Reassigning.
Comment 6 Javier Kohen 2007-11-18 09:29:59 UTC
I can confirm that this happens with at least gedit 2.20.3-1, eog 2.20.2-1 and gthumb 3:2.10.5-2 (Debian versions). GTK+ version is 2.12.1-2.

My recent list contains almost 3000 entries which causes around 6150 stat64 calls on /etc/localtime as a direct result of the repetead calls to gtk_recent_info_get_modified from sort_recents_mru. There is no saving involved in my test case, only loading. See this post I made recently: http://mail.gnome.org/archives/gnome-list/2007-November/msg00054.html

It seems to me that if this information is supposed to be cached, then either it doesn't work at all, or it's not working for this large amount of entries. In any case, it seems that switching to kernel mode twice to handle the stat64 syscall for every comparison in a sort is a bit overkill. Especially when /etc/localtime is very likely to change during the sort operation (and it probably wouldn't matter much if it did, right?)
Comment 7 Christian Persch 2007-11-18 13:06:32 UTC
        return (gtk_recent_info_get_modified (a) < gtk_recent_info_get_modified
(b));

That doesn't look like a valid GCompareFunc. I guess you want "-" not "<" ?
Comment 8 Behdad Esfahbod 2007-11-18 20:48:09 UTC
Good point.
Comment 9 Behdad Esfahbod 2007-11-28 13:01:30 UTC
The large .recentlyused.xbel issue was also making my evo hang for seconds multiple times per minute.  No idea why evo should have anything to do with that file... :(
Comment 10 Emmanuele Bassi (:ebassi) 2008-01-03 12:45:36 UTC
get_modified() just returns a cached timestamp from the RecentInfo structure, so it's not the bottleneck. the amount of recent files entries is probably the cause for slowdowns. see bug 439715 comment 13 for my thought on the matter; in short: GtkRecentManager should never impose expiration policies - it's either done by the views (the panel, nautilus, an applet, even gnome-settings-daemon) or by the user (single/multiple/complete items removal from a dialog or nautilus).
Comment 11 Emmanuele Bassi (:ebassi) 2008-01-03 12:47:39 UTC
(In reply to comment #7)
>         return (gtk_recent_info_get_modified (a) < gtk_recent_info_get_modified
> (b));
> 
> That doesn't look like a valid GCompareFunc. I guess you want "-" not "<" ?

thanks, fixed in trunk and in the gtk-2-12 stable branch

Comment 12 Emmanuele Bassi (:ebassi) 2008-01-06 20:26:49 UTC
*** Bug 507673 has been marked as a duplicate of this bug. ***
Comment 13 Emmanuele Bassi (:ebassi) 2008-01-06 20:27:30 UTC
retitling for clarity
Comment 14 Emmanuele Bassi (:ebassi) 2008-03-18 21:59:34 UTC
*** Bug 523252 has been marked as a duplicate of this bug. ***
Comment 15 Michael Chudobiak 2008-03-28 12:30:11 UTC
A "housekeeping" plugin has been committed to gnome-settings-daemon, to purge the thumbnail cache on a regular basis (bug 523159).

This may be a good place to add recently_used item purging (call it from gsd-housekeeping-manager.c:do_cleanup).

- Mike
Comment 16 Michael Chudobiak 2008-03-29 02:14:10 UTC
I've proposed a gnome-settings-daemon patch in bug 524896 to periodically clean .recently-used.xbel.

- Mike
Comment 17 Paolo Borelli 2008-03-30 16:07:46 UTC
*** Bug 512108 has been marked as a duplicate of this bug. ***
Comment 18 Jon Kåre Hellan 2008-04-01 09:36:42 UTC
With the recent patches, the problem appears to be solved when running under Gnome. However, applications will often be running under other desktop environments. I'm thinking of gnumeric, which does use gtkrecent, and apps like inkscape, abiword and openoffice.org. These applications will still see the file growing without bounds unless running under gnome.

I sympathize with the reluctance to make policy decisions at the toolkit level. But wouldn't it be better to have the file size limited by default, but have the housekeeping plugin in gnome-settings-daemon turn that limit off?
Comment 19 Emmanuele Bassi (:ebassi) 2008-04-01 09:58:13 UTC
(In reply to comment #18)

> I sympathize with the reluctance to make policy decisions at the toolkit level.
> But wouldn't it be better to have the file size limited by default,

as I said, I'd like to - but then gtk+ has no way of changing that setting because gtk+ cannot use gconf or any other configuration system available.

> but have the housekeeping plugin in gnome-settings-daemon turn that limit off?

no, this is incredibly wrong. at this point I'd even consider a GtkSetting property called gtk-recent-file-age-limit and proxing it over XSETTINGS, which is ugly but at least "less wrong".
Comment 20 Emmanuele Bassi (:ebassi) 2008-04-01 12:09:34 UTC
Created attachment 108408 [details] [review]
[PATCH] Clamp items by age

tentative patch, adding the GtkSettings:gtk-recent-files-max-age property and the XSETTINGS property Gtk/RecentFilesMaxAge. the gnome-settings-daemon part will be done later, as well as the GConf schema.

this patch sits on top of my queued changes for using GIO and other changes to GtkRecentManager; it's not meant to be applied on top of trunk - I attached it just for review.
Comment 21 Jens Granseuer 2008-04-01 16:17:02 UTC
*** Bug 524896 has been marked as a duplicate of this bug. ***
Comment 22 Matthias Clasen 2008-04-15 14:14:48 UTC
P_("Maximum age of recently used files"),

Should probably add "in days" here. 
The docs also need to explain the special meaning of 0.


Is the recent_items list sorted by age ? Then you could probably do somewhat better than what clamp_to_age currently does. Of course, that doesn't matter 
as long as we don't call clamp_to_age all the time. How often is it called ?
Comment 23 Emmanuele Bassi (:ebassi) 2008-04-15 14:28:05 UTC
(In reply to comment #22)
> P_("Maximum age of recently used files"),
> 
> Should probably add "in days" here. 
> The docs also need to explain the special meaning of 0.

yep, agree.

> Is the recent_items list sorted by age ?

not at the moment; it could easily be sorted after being read.

> Then you could probably do somewhat
> better than what clamp_to_age currently does. Of course, that doesn't matter 
> as long as we don't call clamp_to_age all the time. How often is it called ?

it's called every time the list is saved after a change (and when forcing a sync on gtk_main_loop_level == 0).

I can rework the patch and presort the list on every read.
Comment 24 Matthias Clasen 2008-04-15 14:29:32 UTC
Yeah, but we can do that when it turns out to be a problem.
Comment 25 Emmanuele Bassi (:ebassi) 2008-04-15 22:37:45 UTC
fixed in trunk

2008-04-15  Emmanuele Bassi  <ebassi@gnome.org>

	Bug 488507 – boundless growth of .recently-used.xbel file
	slows down applications

	* gtk/gtkrecentmanager.c:
	(gtk_recent_manager_init),
	(gtk_recent_manager_real_changed),
	(gtk_recent_manager_set_filename),
	(gtk_recent_manager_clamp_to_age): Clamp the recently
	used resources list by the age of its items, using
	the newly added GtkSettings property.

	* gtk/gtksettings.c (gtk_settings_class_init): Add the
	gtk-recent-files-max-age property, controlling the
	maximum age of the items in the recently used resources
	list.