Developing the Linux kernel with KDevelop

[Milian Wolff]

Alexandre Courbot, 23.09.2011:
> > hm true, tracking the info in something like .kdev_defines might work as
> > well... not sure whether it's fine-grained enough to have that
> > per-directory though.
> 
> This is just a thought, I'm not sure yet about what would be the best
> way to do it. Project-wide settings are probably easier to implement
> for a start. I will try to get a first try done with the generic
> manager, as having the configuration definitions available would
> greatly help me.
> 
> > kdeveop/language/cpp
> > /parser/parser.cpp -> you'll need to adapt that to parse it properly
> > /cppduchain/*builder* -> you'll at least need to change the usebuilder
> > probably for the ".member =" part.
> 
> Thanks. I had a look at it, that seems doable after some more study.
> Second on my list. ;)

In case of questions, feel free to ask me. I've spent some time on that part 
recently and know my way around that code now.

> >> I will also try to get the massif metrics you asked (I already use Git
> >> version). As for memory consumption, parsing the parts of the code I
> >> have specified in the article + a couple of drivers results in around
> >> 1GB of memory used, with a good dozen of files opened.
> > 
> > where do you get that number from? ksysguard? if not, please look at it
> > in ksysguard.
> 
> I was using ksysguard, but these metrics were from months ago. Now
> after a fresh startup, letting the parser go through all the source
> files again, and opening a set of files, ksysguard reports 255MB of
> memory and 124MB of shared memory used. That is much less than, say,
> Firefox. I'm sure it was much more some months ago. The current git
> seems to have received quite a bit of optimization.

Ok, cool. That's even less than what i see personally. I think up to 500MB is 
still OK for larger / many projects in kdevelop.

> >> By today
> >> standards, this seems very acceptable and much better than e.g.
> >> Eclipse anyway. Of course, if you want to parse the whole kernel tree,
> >> this is another story. The parser would take too much time anyway to
> >> make this practical, but this is not a real concern. Lookup is just
> >> fast. Sometimes reverse lookup takes more time than I would expect,
> >> but this is also the case in Qt projects so nothing like a scaling
> >> problem.
> > 
> > Right, but improving the performance to get it working as it should would
> > be cool imo. If you have the time (and a 2.6.x kernel machine + intel
> > cpu), try to run kdev with your kernel project with vtune.
> 
> Good idea - but what do you get more compared to a run with, say, gprof?

Actually useable information and a decent UI. I wouldn't have believed it 
myself but VTune kicks all other profiler's sorry little asses :) Call me a 
fanboy, but I've yet to see anything that comes even near vtune here.

> > as aleix and I said already: We'll be glad to give you a hand. Shout if
> > you have questions.
> 
> Thanks guys. I don't want to take the fun away by asking too much too
> fast, but I will sure come to you if I get stuck somewhere. ;)

nah, don't hesitate - just shoot :)
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110923/f32fe8be/attachment.sig>