On performance of shouldDoDUChainReferenceCounting again

[Milian Wolff]

On Tuesday 12 January 2010 22:34:28 David Nolden wrote:
> 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?

Which one, QWaitCondition::wakeOne? Hmm, I explicitly rebuild Qt with -release 
so I really don't know... But the Dtor of SpinLock gets inlined, I just 
guessed that this is where the QWaitCondition::wakeOne comes from...

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

I'm sadly not very educated in this whole threading/locking issue, but if you 
got the nerve for one more of my questions:

If one disables the wakeOne call, what happens to waiting locks? Sure, the 
case might be rare, but it would still lead to a sleeping thread, no?

Anyways, if you are not sure this works, i.e. if it could easily lead to 
unstable behavior, I'm against pushing the performance here. KDevelop 4.0 
should be stable, not neccessarily blazingly fast (even though it is already 
imo).

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100113/3c779d0d/attachment.sig>