Bugzilla – Bug 113261
Suseconfig.gtk2 using excessive time
Last modified: 2005-09-13 12:20:54 UTC
I timed the usage of SuSEconfig modules on a multiple run (taking a bit of time on a firest run is tolerated, a rerun should better not be above 1 second). Executing /sbin/conf.d/SuSEconfig.gtk2... real 0m21.008s user 0m7.932s sys 0m3.548s regenerating all icon caches on each and every re-run of SuSEconfig is simply a really bad idea.
Looks like the culprit is rm -f $DIR/icon-theme.cache. All the theme caches are being removed, when we really only want to remove the ones in otherwise empty directories, so the entire cache is being rebuilt from scratch each time instead of just the first time.
I tried this with JP's proposed fix, and it works *much* better now. It's still slow the first time, as is to be expected, but later runs are an order of magnitude faster. JP: have you considered hacking on ldconfig? ;-)
Fix submitted, I'm not entirely happy with: test `ls -1 $DIR | wc --lines` -le 3 -a -f $DIR/icon-theme.cache So if you have a better suggestion for determining if the cache file is the only one remaining in the directory I'd like to know.
*** Bug 106592 has been marked as a duplicate of this bug. ***
In beta4, SuSEconfig.gtk2 runs faster, but updates cache incorrectly: - run SuSEconfig Add a package, which adds file to /opt/gnome/share/icons/hicolor/48x48/mimetypes. - run SuSEconfig Nowtilus does not see added icon and only rm /opt/gnome/share/icons/hicolor/icon-theme.cache fixes it. Maybe it is a bug in gtk2, but removing all caches was a good work-around.
The code is supposed to check time stamp differences, it stats the mtime for the cache and the path if updates if the path mtime is newer. So this could be broken, or perhaps gtk/nautilus isn't immediately noticing updates to the icon theme.
I guess that Nautilus will never notice it. Nautilus restart does not help, but cache removal and re-creation helps immediately. I guess, that it does not checks time stamps recursively, which is required especially for default icon themes.
If it is OK for you, I will revert original script. Or I can try to find a heuristics, which can work around gtk2 bug. Something like: find -type d -newer icon-theme.cache
find -type d -newer icon-theme.cache works: test -f $DIR/icon-theme.cache -a "$(find $DIR -type d -newer $DIR/icon-theme.cache)" Fixed dead cache detection - ls -1 in script returns 2 lines less, because aliases are not used: $(ls -1 $DIR | wc --lines) -le 1 Closing as fixed.
Note, you're supposed to only need to check the mtime of the directory because of the following link: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes It states that you only need to update the mtime of the top level directory to make sure caches know to update. This implies that you do need to actually update it. We should probably make sure that packages aren't installing or uninstalling icons without updating the mtime of the top level directory.
*** Bug 116007 has been marked as a duplicate of this bug. ***