changes to duchain lock: can anybody reproduce this speedup?

[Sven Brauch]

Hi,

thanks for trying, Kevin.

On 07/16/2016 01:02 PM, Kevin Funk wrote:
> Note: sched_yield() is not cross-platform. We can't use that directly.
Cool, I would have built something with #ifdef Q_OS_LINUX, but the
QThread API is much nicer of course. Thanks for the hint.

> - CPUs utilized from ~2.0 to ~3.2
> - Time down from ~170s to ~140s.
Ok, nice. I think the reason you see less speedup is because your CPU
only has 2 real cores (mine has 4).

> Main question is: Is KDevelop still functioning without noticable lags, e.g. 
> during typing? All fine?
Didn't do extensive testing. However while we're at this, we should fix
that anyways: if the foreground thread is waiting for a duchain lock,
background threads should just call yield() as well after _releasing_ a
lock. Then you'd basically be guaranteed to always get the lock in the
foreground within at most a few ms (much unlike now, where while a large
project is being parsed in the background, you sometimes even hit the
300ms timeout). There is even a TODO in duchainlock.cpp that something
like this should be done. Of course it might hurt the background parser
performance a bit, but I think that is always a worthy tradeoff for
better UI responsibility.

I will look further into this if Milian doesn't find a reason why the
whole thing is nonsense anyways :)

> QThread::usleep() just puts the *current* thread to sleep, though.
Yeah, but it sets the flag which prevents anything from acquiring a
write lock before. So all other threads needing a write lock can't do
anything either in those 500us, and lots of things in the duchain
builders need write locks.

Have a nice day,
Sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160716/7f466b05/attachment.sig>