Summer of Code is ending (the official deadline for writing code is 20th August) and so my work on the icon cache is also coming to an end.
Yesterday I committed the last crucial piece of code. The cache now periodically checks for icon theme updates, so as soon as you install some new icons, they should be used and the obsolete cache be discarded.
This means that the cache is now fd.o icontheme spec-compliant and all the necessary features should be implemented :-)
Some smaller things remain to be done, such as further performance improvements and final benchmarking. I hope to complete the code part in the coming days and most of benchmarking will probably be done after the 20th.
Speaking of benchmarks, I did some a few days ago. As you have probably heard already, perhaps the most extreme case is kfind which starts up in about 4 secs without the cache and in a bit less than 1 sec (of which just 300ms is icon loading) with the cache. That's with hot caches (i.e. operating system has cached some of the data already). With cold caches it's 12secs vs 2.5secs.
Dolphin uses quite a few icons as well. With cold caches it takes 3.9 secs with iconcache and 5.2 secs without it to start. With hot caches it's 1.2 vs 1.5 secs.
I also noticed about one second improvement (12 vs 13 secs) in full KDE session startup time (with Dolphin, Konqueror, Konsole and KBounce autostarted). I have to admit it's a bit less than I had hoped for, but KDE's startup time will probably be improved prior to 4.0 anyway. Anyway I will make further benchmarks to find out more accurate numbers.
The times are measured from when KPixmapCache contructor is called (which should be at most 100ms after the program is started) until the last find() call (after which the application should be ready to be used).
Subscribe to:
Post Comments (Atom)
10 comments:
Great work! Will you continue to work on this after the benchmarking etc, or do you consider your work now complete?
Also, how frequently are the installed icon themes polled, and how disruptive is this polling (i.e. CPU and hardisk usage; duration of polling; etc)? Can it be manually triggered via the KDE Theme Manager when a new theme is added?
And will you be working on kwin_composite (*drools* :)) some more when you've finished here? ;)
I consider it quite complete and if I manage to get the last few things done then I don't have any bigger things/ideas left. But if I'll get some, maybe I'll continue working on it, we'll see.
Icon themes are polled no more than once every 5 secs and the cache will be automatically discarded when you change icon theme or install new icons, so manual discarding isn't necessary (but is possible).
And yes, after finishing up with soc stuff, I hope to do some kwin hacking again. And maybe another video for beta2 :-)
Great work! Congratulations on completing everything you planned for.
Regarding your reply in the previous comment - if changing icon theme or installing new icons automatically flushes the cache then what is the use of polling (even if atmost once every 5 seoncds)? After all, its rare that icon themes are changed after the initial setup and configuration by a user.
You got it a bit wrong. The polling is what discovers that the icon theme has been changed or modified and as a result the icon cache discards itself. There's no separate application/daemon/whatever deleting the cache when the theme is changed, it's the cache itself.
Awesome work! Thank you so much for your contributions.
I still don't quite understand why the icon themes need to be polled. As the first poster said, why not just flush the caches when the theme is changed via the theme manager? And maybe check once on KDE startup, if it's been changed from outside KDE or something.
Every 5 seconds is ok I guess, but as a laptop user, I would really like this kind of polling to be minimized/eliminated.
As it has been said, maybe the KDE theme manager could be modified so that it sends a signal when a theme is changes/icon set is installed, and your program could act upon that signal in order to avoid the polling. (though that might be actually more resource intensive...dunno actually).
Or you could hack the theme manager so that it automatically triggers a icon cache flush(trough a d-bus call maybe?),making the polling unnecessary.
Since I'm not actually a good coder, I'm just throwing ideas around here :) .
PS: Thank you for the great job with the icon cache. Improving software speed is something that is always looked upon as a great thing(at least by me), and having a fast KDE4 makes a lot of us happy :) . Good job !
Thanks for the clarification. (I posted the 3rd comment) Now I better understand the purpose of polling.
Just a suggestion/remark/observation... Amarok has mechanism whereby they monitor folders for changes to keep an updated database of songs. I think it is called inotify. A quick google search led me to http://www-128.ibm.com/developerworks/linux/library/l-inotify.html.
Not sure if it is relevant and/or useful. If none, atleast a good article.
Thanks for all the work. :)
Thanks very much for all your work on the icon cache.
Every optimisations are always welcome!
I can't wait KDE 4, that will be way snappier!
But I'm worried about the 5 seconds polling.
If I understand it well, every application do a polling on their own, isn't it?
Since they are not launched all at the same time, they poll each at different times. And that polling is only useful arround 1 or 2 times a month, when something changes!
On my desktop I currently have arround 20 KDE applications (counting system tray applications, the few I have on the taskbar and the desktop).
On average, every 5 seconds, 20 applications will do a polling. It means the CPU will be woke up on average 4 times per second?!
Am I wrong?
KDE developers made all their possible for the clock applet to not wake up the CPU every seconds (if seconds are not displayed) to be able to save laptop power. Those efforts would be ruined by the icon cache.
If I'm right, could you try to see how to use inotify or KDirWatcher?
KDirWatcher should work on top of inotify on Linux, dnotify or FAM on other platforms, and perhapse Windows equivalent technology on Windows. It was buggy on KDE 3, but I think they solved issues in KDE 4. Or at least I praise so, because services like Striggi and Nepomuk need to strongly rely on this sort of notifications.
Ok, here's a bit more detailed description about how this polling works:
There are actually no timers involved. Updates to the icon theme are checked for in the KIconCache::find() method. So when an icon is requested from the cache (that's what find() does), then it checks if more than 5 seconds has elapsed since updates were last checked for. If that's true, then it actually looks at the icontheme directories to see if they've changed.
That means that when application is just sitting there doing nothing, it doesn't do any polling at all. Only when you e.g. open a menu and some icons have to loaded does it check for dir updates.
Also, the "polling" is done not per-application but per-system, so if application A checked for updates 2 seconds ago then app B will notice that and won't check for updates itself.
So even with 20 apps running, updates are checked for at most every 5 secs (usually even less often) and cpu is never woken up just to check for updates.
I hope it made things a bit more clear :-)
About doing it via theme manager: it doesn't cover the case where you install an application that adds or updates some icons.
And thanks for the tip, I'll look into using inotify or KDirWatcher.
Thanks for explaining your solution. I guess not looking at the code, I made the worst case assumption. My bad.
And thanks for all your work on KDE.
Post a Comment