KCachegrind, Take 2

[Josef Weidendorfer]

Hi,

On Friday 06 September 2002 12:32, Stephan Kulow wrote:
> Am Freitag 06 September 2002 09:27 schrieb Ralf Nolden:
> > On Freitag, 6. September 2002 03:09, Josef Weidendorfer wrote:
> > > What is your opinion on importing KCachegrind into the kdesdk package?
> >
> > I would be very much in favour for that. I think many people also would
> > like to have something like KValgrind, too.
A GUI is only usefull with quick jumping to source code, e.g. in KDevelop.
For emacs a output parsing script (like fro compiler errors) should be enough.
I got a EMail from someone doing a KValgrind Part for Gideon...

A GUI for developers makes only sense for quick and simplified overview / or 
integration of different tools.
I made KCachegrind because I didn't see the performance problems in the 
vg_annotate output (way too much information giving too much details).
That's the reason I do all this summing up and function grouping.
That's also the reason I implemented the TreeMap Graph widget from scratch:
A picture says sometimes more than thousand numbers...
But even if it's looking fine, the is the problem that for lots of calls you 
only have the "pyramids" effect and don't see real costs :-( Has somebody
a idea for that? Without border you can see any call structure (I experimented 
with different colors, too). And beside from that, there is the problem with
recursive calls. Here, the Coverage List is much more effective.

Another problem I have is the best layout for all the information provided, 
supporting quick and easy usage patterns. What do you think of the situation 
with the actual KCachegrind?

> >
> > > Surely not before KDE 3.1 (think of translations etc.), or ?!?
> >
> > Yes. And Valgrind itself would be a requirement for using it (as a
> > dependency). Is there anything planned to put that into CVS, too ?
>
> It is in CVS, check sourceforge.net
Probably he meant my valgrind patch. I could put it into CVS and sync 
regularly with official valgrind - as long as my patch is separate: It 
doesn't have that much testing, and we can put it into valgrind 1.0.x. I 
don't know when valgrind 1.1 or 2.x will appear.

>
> Greetings, Stephan