sebastianmarconi@xxxxxxxxx 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 <silver@xxxxxxxxxxxxxxxxxxxx>
ChatZilla Developer
|
