GSoC 2010: Making KDevelop suitable for large C projects

Niko Sams niko.sams at
Mon Mar 29 20:02:57 UTC 2010

On Mon, Mar 29, 2010 at 21:48, Nitin Gupta <ngupta at> wrote:
> On 03/30/2010 12:37 AM, Andreas Pakulat wrote:
>> On 29.03.10 23:16:06, Nitin Gupta wrote:
>>> On 03/29/2010 06:03 PM, Milian Wolff wrote:
>>>> Nitin Gupta, 27.03.2010:
>>>>> For past few months, I have been working on a simple IDE (called KXref)
>>>>> based on Sublime UI framework, to allow working with large C based
>>>>> projects (Linux kernel in particular):
>>>>> However, I soon realized that it will be much more useful and productive if
>>>>> all this can be developed as plugins for upcoming KDevelop4. My initial
>>>>> attempt to get it working for Linux kernel failed badly primarily due to
>>>>> lack of cscope, or better GNU global, integration (built-in background
>>>>> parser is too slow for such large projects). There are many other factors
>>>>> which make it unsuitable for kernel projects (as detailed below).
>>>>> Unlike popular belief, an IDE for kernel projects (IMHO) is highly
>>>>> desirable. Trying to understand such huge and complex codebases is almost
>>>>> impossible otherwise. Plain vim+ctags is often not sufficient.
>>>>> I'm planning to submit this as a GSoC proposal. I would be thankful for any
>>>>> feedback.
>>>> My personal opinion is: One can integrate each and every tool there is for
>>>> KDevelop, but I'd much prefer improving the performance of the build in parser
>>>> instead of using yet another tool for the job...
>>>> I found quite a few places to optimize over the weeks, and I bet there are
>>>> more.
>>> Built-in parser seems to be slow beyond repair. Following is test summary:
>> I suggest you back that statement up by some knowledge about the
>> codebase. Making such blanket statements won't get you much friends
>> around here ;)
> Yes, I should have gathered proper profiling data but the numbers are still very
> disappointing. Argument that its all done in background with preference
> given to opened files isn't too nice -- with large C project containing 20k - 30k
> files, the parser (in its current form) can take hours pumping CPU at nearly 100%.
> Maybe improving in-built parser speed is the way to go but it was too tempting
> for me to go for already optimized solutions like gtags even if they could not
> provide as much of information as in-built parser.
> Maybe we should have options for in-built parser like: more comprehensive parsing vs speed.
> I think this will quickly make KDevelop suitable for large projects while it is gradually
> optimized.
This option is already avaliable, see Configure Kdevelop -> Language
Support -> Project parsing ->
Minimum project size for simplified parsing
Afaik it does still the whole parsing  but does simplified DUChain
building. Maybe other things
can be simplified to improve performance.


More information about the KDevelop-devel mailing list