On performance of shouldDoDUChainReferenceCounting again

David Nolden zwabel at googlemail.com
Tue Jan 12 21:34:28 UTC 2010


Am Dienstag 12 Januar 2010 19:11:57 schrieb Milian Wolff:
> Hey all, esp. David ;-)
> 
> Hope it's OK if I ask a bit again about the performance of
> KDevelop::shouldDoDUChainReferenceCounting (not ...Internal).
> 
> It turns out that it is now (incl. costs) repsonsible for 40% of the total
> cost during parsing the big PHP internal function file. I don't pass any -
> threads parameter to duchainify, is it now using two threads by default?
>  Yet I'm only parsing a single file, hence it should use a single thread.
>  Anyways, I find it kinda krass that this function and it's children spent
>  40% for a "simple" bool-check...
> 
> Here's my profile:
> https://userpage.physik.fu-berlin.de/~milianw/callgrind.out.29477.bz2
> 
> As you can see 72% of the 40%, i.e. 30% total, are spent in
> QWaitCondition::wakeOne(). As far as I can see this would be called in the
> dtor of the SpinLock.
> 
> Is there anything we could do to improve this?

Actually that function should be inlined. Why does it even show up in your 
profiling output?

Apart from that, we could disable the wait-condition fallback in this specific 
spinlock by adding a third bool template parameter called "useWaitCondition" 
and disabling it in this place, so it simply doesn't call wakeOne() and 
doesn't use the wait-condition and mutex at all. I think the lock-contention 
in this function is very low, so it shouldn't matter that much (which needs 
some multi-threaded testing though). If we set mSleep to zero, even high lock-
contention shouldn't matter much.

Greetings, David




More information about the KDevelop-devel mailing list