mmm... no idea really. we do not call gtk_recent_info_get_modified directly... maybe a bug in that version of gtk?

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.

The .recently-used.xbel in question has 4200 bookmark entries, mostly photos.

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.

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:

+ Trace 174727

May just be the unbounded growth...  Reassigning.

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?)

        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 "<" ?

Good point.

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... :(

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).

(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

*** Bug 507673 has been marked as a duplicate of this bug. ***

retitling for clarity

*** Bug 523252 has been marked as a duplicate of this bug. ***

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

I've proposed a gnome-settings-daemon patch in bug 524896 to periodically clean .recently-used.xbel.

- Mike

*** Bug 512108 has been marked as a duplicate of this bug. ***

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?

(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".

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.

*** Bug 524896 has been marked as a duplicate of this bug. ***

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 ?

(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.

Yeah, but we can do that when it turns out to be a problem.

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.