kdevelop 4 parsing on opensuse 11.2 is extremely slow for linux kerenl project

[Milian Wolff]

Christoph Bartoschek, 02.04.2010:
> Am Freitag 02 April 2010 schrieb Christoph Bartoschek:
> > I've also tried to import the linux kernel tree. However I do not see
> > that parsing is slow. I would say that the problem lies in the
> > IncludePathResolver. My observations are:
> > 
> > 1. During importing kdevelop only takes 10-25% CPU time.
> > 2. The IncludePathResolver changes the timestamps of the files all the
> > 
> >  time and it seems as if a FileSystemWatcher is fired because of the
> >  changes within kdevelop. (Why is the resovler not using the option
> >  --assume-new provided by make? At least if the make is GNU make)
> 
> I've just seen in the code that there is code that is able to use the --
> assume-new option. However the timestamps are still always updated. Why is
> this not enabled?
> 
> I've made the following experiment. I've disabled the IncludePathResolver:
> it always returns false.
> 
> Now the whole linux kernel is initialy parsed in 15 minutes on my machine.
> I've tried to load it with the Resolver enabled but gave up after 2 hours
> and 5% loaded.

I'll do some more profiling the next days on the Linux Kernel, lets see whether 
I find anything interesting. But regarding 15 minutes vs 2h+:

When you simply disable the IncludePathResolver - you probably "only" parsed 
the c files in the Kernel, no system includes (I don't know if there are any in 
the Kernel, but glib or stdlib are probably used?).

Anyways, I'll investigate, lets hope we find something to improve!

> In my experiment I used 4 parser threads but I see only 144% CPU time on my
> 4-core-machine. This means that kdevelop still wastes lots of time waiting.
> I do not know for what it waits: mutexes or I/O.  Unfortunately I do not
> know a good profiler that is able to analyze waiting time. Callgrind is
> definitively the wrong one.

Hamish once pointed out the following tool:

http://0pointer.de/blog/projects/mutrace.html

I never used it, but it seems to be promising for this usecase.
-- 
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: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100402/f157acb8/attachment.sig>