I dug a bit
deeper into the cachegrind results with tdecachegrind and
spotted an obscure codepath that was responsible for a significant
fraction of the startup instructions. I have committed a patch for that
problem in GIT hash 30c5994; can you please rebuild TQt3 and see if the
slow startup time is resolved? You don't have to rebuild tdelibs or
anything else, just TQt3.
I rebuilt tqt3 with the latest commit. My stopwatch tests:
GIT shortlog version 8443, Oct. 30
kate: 1.54, 1.29, 1.35; avg.: 1.39
konqueror: 1.47, 1.61, 1.57; avg.: 1.55
kmail: 2.09, 1.96, 1.97; avg.: 2.01
GIT shortlog version 8665, Nov. 10, tqt3 patched with commit 30c5994
kate: 1.84, 1.50, 1.51; avg.: 1.62
konqueror: 1.70, 1.73, 1.70; avg.: 1.71
kmail: 2.48, 2.58, 2.49; avg.: 2.52
GIT shortlog version 8665, Nov. 10, tqt3 unpatched
kate: 1.97, 1.94, 1.80; avg.: 1.90
konqueror: 3.60, 2.83, 3.21; avg.: 3.21
kmail: 3.72, 3.39, 3.47; avg.: 3.53
Quantitatively, improved from the unpatched, slower than Oct. 30.
Qualitatively, I notice but how much other users will notice remains
unknown.
Darrell
OK, to debug further can you please run this using the latest GIT code:
valgrind --tool=callgrind kmail --nofork
immediately exit kmail, and send me the generated callgrind.out.<pid>
file? I can then use that file to analyze the execution of the code on
your machine and see if there is another suboptimal codepath in use.
At least the numbers are now generally within 1/2 second of the original
numbers...
Thanks!
Tim