I mean these analysis:
http://www.gnome.org/~lcolitti/gnome-startup/analysis/
Tell me if I am wrong but has KDE something to gain in this department?
Using mmapped data structures and/or RAM-disk? Using Suspend-To-Disk-Like trick so most, once prelinked, libraries can be saved to disk and restored on next startup just in one second by loading one large file?
Or, unlike in GNOME, it's no longer KDE problem, and we should rather look at things like faster loading shared libraries?
Syndicate Blogs
UPDATE: Intel is here to help us :^)
..thanks to its new Robson technology
[..]The laptop with Robson also opened Adobe Reader in 0.4 seconds, while the other notebook required 5.4 seconds. It opened Quicken in 2.9 seconds, while the laptop without Robson technology needed 8 seconds to do the job.[..]
No, this doesn't mean we don't need to improve startup for users without Robson technology on their desks...
System startup / bootchart
I have done a test with bootchart to check the start time for KDE.
1) bootchart start
2) start KDE
3) bootchart stop
4) use this web site to render png of /var/log/bootchart.tgz
http://bootchart.klika.si:8090/bootchart/render
In my case, it take 30seconds for a cold start, mostly IO bound. Log out of KDE of login again, the startup decrease to 20 seconds with almost no IO (with a huge 5s window where kcminit run with CPU and IO close to almost zero).
I don't have a web site to post the image, but it is pretty easy to do the measurement.
30 seconds to start KDE - what version? What hardware?
Hi Patrick,
can you give more information about your
system? What hardware, what OS, what version of KDE?
Thanks!
p.s. Lubos has some measurements on
as-yet-unreleased versions of KDE and fontconfig with warm caches at
http://www.kdedevelopers.org/blog/280
Yes please!!
Many of the issues in that article are strictly GNOME-related but I doubt not that KDE has bottlenecks that could profit from the same sort of analysis. Do you think up to doing it yourself? (No offense intended!! I just don't know what level of involvement you have in KDE X.x)
Hmm
Being 150% busy with Kexi and kdelibs/win32, I think it is a task for someone other, perhaps within Google Summer of Code 2006?
inter application time measuring
While porting KDE to cygwin I was faced to the fact that starting KDE applications goes through many processes
app (kdecore/dcop) -> dcopserver -> kdeinit -> forking new app and so on
and that time measurement is very hard to perform.
For that some people wrote a simple application profiler http://cvs.sourceforge.net/viewcvs.py/kde-cygwin/tools/profiler, which collects timing informations from multiple applications
Then we added specific profiler calls into important kdecore points like lib loader and so one to get an idea who long several task runs.
May be this could help to track down more time related issues.
Regards
Ralf
Definitively...
To blame the others --a lack of faster shared libraries loading system-- isn't the solution until KDE makes virtually all that's possible to speed up its starting process. At that time we will be allowed to complain that it's not "our" fault. But we're not there yet.
If somebody would like to volonteer to do such an analysis of KDE startup, that would be very useful to know what KDE is doing hidden behind its splash screen.
Any way, I think that KDE suffers from the same disease than Gnome: the "harddisk bottleneck syndrome".
Maybe one first step in the right direction would be to let KDE be configurable in order not to waste time on situations that would never arise on one local computer. For example, I don't spend time moving KDE in every corner of my harddisk every day. Some more specific scripts only for my configuration may help me gain a few seconds. Just an idea from the top of my head...
But your idea of Suspend-To-Disk-Like is the absolute solution. I like that! We would have to resort to a sluggish startup only when absolutely required: when we update KDE or one of its libs. I don't believe we could go any faster...