>> 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