GSoC 2010: Making KDevelop suitable for large C projects

[Niko Sams]

On Mon, Mar 29, 2010 at 21:48, Nitin Gupta <ngupta at vflare.org> 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): http://code.google.com/p/kxref/
>>>>>
>>>>> 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.

Niko