GSoC 2010: Making KDevelop suitable for large C projects

[Nitin Gupta]

On 03/30/2010 05:56 AM, David Nolden wrote:
> The right way to go is making the simplified parsing faster. In
> simplified parsing mode only a very reduced amount of information is
> collected, mostly just the function names and some information about the
> #include structure. I think the slowest part is the stored meta
> information from the preprocessor, we should consider further reducing
> that information. Profiling will help. One thing is for sure: we can
> make the simplified parsing a lot faster, and that's the right way to
> go, as opposed to creating plugins for random additional tools, be it
> gtags, ctags or whatever.
> 

Yes, I have now shifted the focus to optimizing the parser rather than
an new gtags/etc. plugin. I'm now trying to understand and profile duchain
code to identify areas of bottleneck and to help prepare GSoC application
just focusing on this optimization work. I really want to see KDevelop
useful for large projects -- just like KScope was indispensable for
hacking on the kernel code.

Thanks,
Nitin




>> Am 29.03.2010 22:38 schrieb "Nitin Gupta" <ngupta at vflare.org
>> <mailto:ngupta at vflare.org>>:
>>
>> On 03/30/2010 01:31 AM, Milian Wolff wrote:
>> > On Monday 29 March 2010 21:48:23 Nitin Gupta wrote:
>> >>...
>>
>> After feedback from you all, I'm now thinking of simply dumping on all
>> this gtags
>> stuff. It was especially good to know that we have comprehensive
>> parsing vs speed
>> switch in the parser. I just tried that but reducing:
>>  "Minimum project size for simplified parsing" to 1000 so that the
>> project does use
>> faster parsing but that does not seems to be any faster.
>>
>> Anyways, the point now is that it will be really exciting to see where
>> the bottlenecks
>> are. One simple observation from gtags is that it never uses multiple
>> cores while the
>> built-in parser drives both CPUs (dual core machine) to nearly 50%-60%
>> constantly. Even
>> then the parser (even simplified parsing) is so much slower. I think
>> optimizing this
>> parser is worth a project in itself.
>>
>>
>>
>> >> Maybe we should have options for in-built parser like: more
>> comprehensive
>> >> parsing vs speed....
>>
>> Got your point. I will try dig through DUchain code, learn userspace
>> profilers and
>> maybe understand and fix the bottlenecks.
>>
>>
>> Thanks,
>> Nitin
>>
>>
>> -- 
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org <mailto:KDevelop-devel at kdevelop.org>
>> https://barney.cs.uni-p...
>>