GSoC 2010: Making KDevelop suitable for large C projects

David Nolden zwabel at
Tue Mar 30 00:26:50 UTC 2010

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

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
stuff. It was especially good to know that we have comprehensive parsing vs
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
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.


KDevelop-devel mailing list
KDevelop-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KDevelop-devel mailing list