GNOME Bugzilla – Bug 439715
GtkFileChooser - recent files option takes up 100% CPU.
Last modified: 2007-07-20 10:40:25 UTC
When choosing Recent files in the new GtkFileChooser my CPU utilisation go up to 100% for about 5-7second. This is on a AMD X2 3600+ system. I know this may not be a gtk+ issue but if the Recent files dialog did not show so many files at ones the problem would go away? Other information: gtk+(SVN)
does the CPU usage reaches 100% when showing the list of files on the panel or inside an application? does this happen when you run the testrecentchooser application in gtk+/tests? could you please run the testfilechooser application in gtk+/tests under a profiler like oprofile or sysprof and attach the results here?
(In reply to comment #1) > does the CPU usage reaches 100% when showing the list of files on the panel or > inside an application? > Its inside an application when using the new Recent files in the GtkFileChooser. > does this happen when you run the testrecentchooser application in gtk+/tests? > This don't happen when running the testrecentchooser, but if i run the testfilechooser or autofilechooser and click on "Recent files" it happens. The Recent files show ALL my recent files since 2007-03-19 and thats alot of files. > could you please run the testfilechooser application in gtk+/tests under a > profiler like oprofile or sysprof and attach the results here? > I tried to run testrecentchooser/autofilechooser through sysprof but it won't work. I think it want's a binary but the files in test is shell scripts.
(In reply to comment #2) > (In reply to comment #1) > > does the CPU usage reaches 100% when showing the list of files on the panel or > > inside an application? > > > Its inside an application when using the new Recent files in the > GtkFileChooser. I meant: does this happen also with those two recent files viewers or not? > > does this happen when you run the testrecentchooser application in gtk+/tests? > > > This don't happen when running the testrecentchooser, but if i run the > testfilechooser or autofilechooser and click on "Recent files" it happens. The > Recent files show ALL my recent files since 2007-03-19 and thats alot of files. the testrecentchooser has a limit of 20 items; we should probably limit the same way the recent files view in the file chooser, event though I didn't experience any spike like the one you're reporting on my system. > > could you please run the testfilechooser application in gtk+/tests under a > > profiler like oprofile or sysprof and attach the results here? > > > I tried to run testrecentchooser/autofilechooser through sysprof but it won't > work. I think it want's a binary but the files in test is shell scripts. you should use libtool --mode=execute sysprof ./testfilechooser under your gtk+/tests directory. this would give me some more numbers to decide where to cut off the size of the returned list.
(In reply to comment #3) > you should use > > libtool --mode=execute sysprof ./testfilechooser > > under your gtk+/tests directory. this would give me some more numbers to decide > where to cut off the size of the returned list. > I get this from sysprof: "Could not open /home/filip/source/gtk+/tests/.libs/lt-testfilechooser: Fel på rad 1 kolumn 1: Dokumentet måste börja med ett element (exempelvis <book>) [OK]" In English: "Could not open /home/filip/source/gtk+/tests/.libs/lt-testfilechooser: Error in row 1 column 1: The document must start with an element (for example <book>) [OK]"
oh, right you need to start sysprof, start the data collection and then start the testfilechooser test. switch between recently used and browse ten times or so, then stop the data collection. then save the data collected and attach it to the bug report.
Created attachment 88452 [details] Sysprof log from GtkFileChooser I get the same error message when doing that, but i used the filechooser in sysprof and got some results. Here they are.
Thanks for the sysprof log, Filip :) Do you have an estimate of how many files get shown in the list? [If you don't have confidential data, could we take a look at your ~/.recently-used.xbel?]
in alternative, if you don't want to attach the .recently-used.xbel file, you can run: grep "href=" ~/.recently-used.xbel | wc -l to get the number of entries.
(In reply to comment #8) > in alternative, if you don't want to attach the .recently-used.xbel file, you > can run: > > grep "href=" ~/.recently-used.xbel | wc -l > > to get the number of entries. > $ grep "href=" ~/.recently-used.xbel | wc -l 1710
(In reply to comment #7) > Thanks for the sysprof log, Filip :) Do you have an estimate of how many files > get shown in the list? > > [If you don't have confidential data, could we take a look at your > ~/.recently-used.xbel?] > Sorry Federico, its not confidential but there is personal stuff i don't want floating around :)
(In reply to comment #9) > $ grep "href=" ~/.recently-used.xbel | wc -l > 1710 thank you. we need to limit the results to a more manageable number.
Is this just the "recent files grows without bounds" issue, or is this filechooser-specific ? Any thoughts on the former, Emmanuele ?
(In reply to comment #12) > Is this just the "recent files grows without bounds" issue, or is this > filechooser-specific ? unlike the GtkRecentChooser implementation, the recent files support inside the GtkFileChooserDefault widget is not doing any kind of clamping on the list. I have a patch in my queue for adding a GtkSetting property for setting a common limit for every widget showing the recent files list, and the file chooser should respect that limit too. > Any thoughts on the former, Emmanuele ? the idea when writing GtkRecent was to drop the bounds that EggRecent had (500 entries max), but since there's no way to actually delete a file from the list in the current viewers on the platform, the list can grow pretty much unchecked. as I see it, this is not a problem in gtk+ itself: it's a problem on the GNOME side. nautilus should be able to show the recent files list as a folder (I'm working on such patch) and remove entries from it; the panel should be patched to optionally show the whole list (using a GtkRecentChooserDialog) and let the user remove files from it; finally, the context menu of the file chooser when in OPERATION_MODE_RECENT should allow the user to remove a file from the list (not actually delete the file itself). another option would be making the GtkRecentManager smart enough to go through the list and silently remove entries older than N days, but I'd rather not do that - it's really something that the user should decide.
Thanks, three good proposals, imo
Created attachment 88659 [details] [review] Add a setting for the recent files limit This patch adds a new property to GtkSettings called "gtk-recent-files-limit", controlling the maximum number of recently used files that should be displayed by GtkRecentChooser implementations and by the GtkFileChooser default widget when in OPERATION_MODE_RECENT. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtksettings.c | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-)
Created attachment 88660 [details] [review] Use the recent files limit setting This patch adds support for the newly added "gtk-recent-files-limit" property of GtkSettings inside the GtkRecentChooser implementations. The property is checked when populating the list, by querying the GtkSettings object attached to the same screen as the widget. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkrecentchooserdefault.c | 28 ++++++++++++++++++++++++++-- gtk/gtkrecentchoosermenu.c | 20 ++++++++++++++++++++ 2 files changed, 46 insertions(+), 2 deletions(-)
Created attachment 88661 [details] [review] Sort when loading the recent files list Do a preliminary MRU sort when loading the recently used files list. This is needed in order to later clamp the list without losing meaningful entries. Also, bail out of the recent files loading loop if the GtkRecentManager returns an empty list. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserdefault.c | 28 ++++++++++++++++++++++++++++ 1 files changed, 28 insertions(+), 0 deletions(-)
Created attachment 88662 [details] [review] Clamp the recent files list in GtkFileChooserDefault Read the gtk-recent-files-limit property from the GtkSettings and correctly clamp the recent files list returned by the GtkRecentManager, after sorting it. This change makes the list smaller and the reduces the performance impact of loading the recent files list inside the files list tree view. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserdefault.c | 46 ++++++++++++++++++++++++++++++++++++++---- 1 files changed, 41 insertions(+), 5 deletions(-)
this set of patches should fix the problem reported in this bug, by reducing the size of the recent files list in the GtkFileChooser default implementation. the length of the list is controlled in every recent-files viewer widget by the gtk-recent-files-limit property of GtkSettings.
Hmm, it may be more complicated, but with a custom tree model, it should be possible to load things on demand, no ? It is a bit bad if the user has a limit of 50, and the file he needs is the 51st, which is still in the file, but there is no way to get to it...
the file chooser is already loading "on demand" - if I understand what you mean; the CPU spike is not due to the recent manager returning a thousand items - it's due to adding them all. also, there already is an artificial limit of hits returned by the file chooser in search mode, so it would make sense to add such limit in recent files mode too.
ok then.
*** Bug 458391 has been marked as a duplicate of this bug. ***
*** Bug 362374 has been marked as a duplicate of this bug. ***
Created attachment 92005 [details] [review] Cumulative patch for limiting the list of recently used files this is the cumulative patch, adding the GtkSettings:gtk-recent-files-limit property controlling the length of the displayed list of recently used files. the limit is only applied to GtkRecentChooserWidget and to the file chooser in recent files mode, as a menu should not display more than 10/15 items. the default value is 50 and can be tweaked; in the next release we might even add an XSetting for it, so it can be controlled by the settings daemon. the patch contains also a couple of other fixes, like adding a five seconds barrier to the stat() of the recently-used.xbel file, if the manager hasn't changed between timeouts.
2007-07-20 Matthias Clasen <mclasen@redhat.com> Apply a patch by Emmanuele Bassi to limit the number of shown recent files. (#439715) * gtk/gtksettings.c: Add a setting for the number of recent files to display by default. * gtk/gtkrecentchooserdefault.c: * gtk/gtkfilechooserdefault.c: Respect the limit. * gtk/gtkrecentmanager.c: Remove the poll timeout in dispose, and do not stat more often than every 5 seconds. * gtk/gtkrecentchooserutils.c: * gtk/gtkrecentchoosermenu.c: Cleanups * tests/testrecentchoosermenu.c: Test limits.