Thread-safety issue in cmake support ?

[Milian Wolff]

Nicolás Alvarez, 11.06.2010:
> On 6/11/10, David Nolden <zwabel at googlemail.com> wrote:
> > The big lock wouldn't eliminate multithreading at all.
> > 
> > For example in the c++ support, it is needed only once at the beginning
> > of a parse job to get the include paths, and maybe a few times during
> > the code completion, which is quite tightly coupled to the UI anyway.
> > Ok, it would also be required for using the new smart-ranges for
> > highlighting, but that could be combined into one single locking per
> > parsed open document, and thus wouldn't be critical.
> > 
> > The important task is just to make sure the lock is used as seldomly as
> > possible, and to make sure that all the heavy-lifting is done in a long
> > continuous phase without the lock. That is easy for c++ support at least.
> 
> In my experience, the C++ parser *already* has too much lock
> contention (from duchain locks). I rarely see KDevelop CPU usage go
> above 100%.
> 
> I just tried wiping .kdevduchain and starting kdevelop again, and it
> averaged 85% CPU usage during background parsing. It's configured to
> use 2 threads and doesn't even manage to use a single CPU core
> fully...

I agree completely. I know from the few times I did such tests that two 
threads make parsing a big project only roughly 10% faster while three didn't 
improve that noticeably anymore...
-- 
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/20100611/d7b76bce/attachment.sig>