GSoC 2010: Making KDevelop suitable for large C projects

[David Nolden]

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.

Greetings, david

Am 29.03.2010 22:38 schrieb "Nitin Gupta" <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
https://barney.cs.uni-p...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100330/50e81e64/attachment.html>