Version: 1.9.1 (using KDE KDE 3.5.1) Installed from: Unlisted Binary Package Compiler: gcc version 3.4.5 Configured with: /var/uhubuild/work/compile/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++ --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --host=i586-uhu-linux; Thread model: posix OS: Linux kmail startup sometimes takes at least 20sec, but inside this 20sec period there is a 10sec gap, where processor usage is ~0%. I think it should be faster.
Do any other KDE apps show similar behaviour? Problems like this can be caused by incorrect network settings.
As I see no other apps do the same I suspect that some race condition is occuring between accidentally launched multiple kmail processes (https://bugs.freedesktop.org/show_bug.cgi?id=5765).
Sounds plausible. Can you try starting kmail using something other than the multimedia keys, so you can confirm your hypothesis?
Well, my current results seem to ruin the expectation, I rebooted my computer, started IceWM, xterm, and launched one istance of kmail by typing kmail and hitting enter. The startup was as slow as launching kmail by the multimedia key, with the no-cpu-load present as in the previous case.
Still present in 1.9.3 kde 3.5.3.
Does KMail probably wait for responses of servers? If you enabled fetching mail on startup then KMail will check for new mail before the window appears. Depending on the number of accounts KMail has to check this might of course take some time, especially with IMAP accounts. And while KMail waits for a server's response it does of course not use any CPU. Please try whether disabling "Check mail on startup" helps.
If you enabled fetching mail on startup then KMail will check for new mail _after_ the window appears. As I see. I will test with "Check mail on startup" disabled. It will take long time.
I found that 20sec gap in the startup of kolourpaint too. Maybe it is just present at the first startup of a kde process after reboot (I use IceWM). I will attach output.
Created attachment 17171 [details] kolourpaint output
That does explain your observation. If you start the first KDE apps then a lot of KDE services need to be started and initialized. Since the services are automatically shutdown when you close this KDE app the next start of a KDE app will again take some time. I hope it's okay that I close your report.