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

[Benjamin Schindler]

Hi

On 02.04.2010 15:51, Milian Wolff wrote:
> 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?).

No, the kernel is completely self contained. It cannot have any
dependencies - how could it.
So in that regard it's close to the situation I gave you with my
boost-example

Cheers
Benjamin


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