call graph

[Neil Bowers]

Hi,

As suggested, I've lashed up a mod to nytprofcalls on the sofa tonight. I had a slight WTF moment when looking at the graph, assuming I'd done something wrong, but when looking at the the module I was using, realised that's where the WTF lived. I haven't really got my head around the data structure, but I'm getting useful output. Now I need to have a think about how to produce a more compact and useful graph structure.

That did appear to reveal though, that the call paths spat out appear to be based on parsing rather than running the code? I haven't dug into what the data exactly is, or where it's coming from yet, and the documentation is a bit lacking :-)

Cheers,

Neil

[Neil Bowers]

If you look at the graph I attached last night, you can just about see that there are three calls off main. The bottom one (which results in the largest part of the graph) is "use Module", and then the module has a lot of "use constant". So I'll probably have the default output suppress / reduce this stuff, as I suspect that most of the time the interesting part isn't this sort of stuff.

I'll also weight the edges.

Neil

[Tim Bunce]

On Tue, Apr 16, 2013 at 04:06:47PM -0700, Neil Bowers wrote:
> Hi,

Hi Neil.

> As suggested, I've lashed up a mod to nytprofcalls on the sofa tonight. I had a slight WTF moment when
> looking at the graph, assuming I'd done something wrong, but when looking at the the module I was using,
> realised that's where the WTF lived. I haven't really got my head around the data structure, but I'm
> getting useful output. Now I need to have a think about how to produce a more compact and useful graph
> structure.

I can't read any detail on the image (generating an svg or pdf would be
great) but it looks like you're aggregating all the calls together. So
if A calls B five times you just get one line.

If that's the case then the event stream (and nytprofcalls) probably
isn't the best approach.

If you just want aggregated stats on all the call arcs (A called B five
times taking X seconds) then the data is available more directly.

The nytprofhtml code already generates .dot files for the arcs.
The files are called packages-callgraph.dot and subs-callgraph.dot.
See output_subs_callgraph_dot_file() in nytprofhtml.

The links are on the index page just below the top 15 subroutines table,
where it says "NYTProf also generates call-graph files in Graphviz
format: inter-package calls, all inter-subroutine calls".

> That did appear to reveal though, that the call paths spat out
> appear to be based on parsing rather than running the code?

That seems very unlikely. You might be confused by calls made at BEGIN
time, ie during compilation. Working with really small examples would
help spot any problems.

> I haven't dug into what the data exactly is, or where it's coming
> from yet, and the documentation is a bit lacking :-)

Too true. Please do add rough notes and questions into the pod as you go
along and I'll polish them up and flesh them out.

Much of the code is in dire need of refactoring.

Tim.

[Neil Bowers]

I can't read any detail on the image (generating an svg or pdf would be
great) but it looks like you're aggregating all the calls together.  So
if A calls B five times you just get one line.

In that version, yes, but I want to overload the #calls onto this. So far I've been playing with setting penwidth and weight to try and get a more useful visualisation of the call graph. I'll have a closer look at nytprofhtml, since that might be easier to work with. Still haven't got my head around the data in nytcallgraph. I blame the wine.

Neil