Re: Profiler in Callgrind format

[email protected] wrote:
> Hello,
> I'm a co-developer of (yet another) a web framework...Being mainly a
> server-side programmer, after profiling the execution using Venkman
> (and now also the great firebug1.0 feature) I miss the visualization
> quality of tools like KCacheGrind or WinCacheGrind that uses the
> Callgrind Format. We have a lot of classes and complex (ajax) things,
> and the tabular output doesn't fit very well  (this kind of framework
> may be useless, but there's where we and thousands are) you can't
> follow specific threads of execution, you don't know who the callers
> and calles are, even the memory consumption is missed.

Memory consumption is neigh on impossible to calculate with SpiderMonkey 
because it shares all sorts of objects, not only between things in your 
scripts, but often with the host application.

Following individual execution paths is indeed a limitation of the 
current profiling code which is, in all fairness, exceptionally simple. 
It certainly wasn't meant to care who calls who, and adding such would 
be (probably) a rewrite of most of the existing profiling code.

Different layouts of the data we do have might well be very useful, 
though. :)

> Seeking this goal, I've started to develop an extension using
> jsdIDebuggerService, but it's not enough because for callgrind you need
> a step-by-step execution (horrible for performance) and jsdlDebugger
> gives you pre-processed information. What do you think? Is it possible
> to write an specific XPCOM component or improve the actual one?

What do you mean "pre-processed"? Are you referring to the access to 
profiling data? The debugger service is quite sufficient to single-step 
through all the code, although it might be a big performance hit (hardly 
surprising). You'd have to do all the work tracking profile data.

I don't know how feasible trying to do your own XPCOM components for JSD 
is - you'd have to effectively replace the entire thing, I think, as the 
profiling is all down in the C code and not in the XPCOM interface 
(jsd_xpc.cpp) that exposes it to the world.

> I'm not blaming the current work, works very well for nearly all the
> projects, but I think that a more powerfull profiler is needed in the
> today's javascript. Am I crazy?

Only as crazy as the rest of us. ;)

If you would like to see any of your ideas in JSD in the future, you 
should file bug reports at https://bugzilla.mozilla.org/ (Product: Other 
Applications, Component: JavaScript Debugger). Nothing will happen 
overnight, but it's always better to know what is actually wanted than 
to guess and get it wrong.

-- 
James Ross <[email protected]>
ChatZilla Developer