Follow up on profiler development

[Jordi Gutiérrez Hermoso]

Hello, Daniel. A number of things.

Can you in fact provide some gprof output (run a few demos or tests)
and make sure that the profiling code functions are all very low in
the profiling output? Let me know if you manage. I had some trouble
writing profiling instrumentation data into the Octave binary with
gprof, so I used oprof instead. If you also have trouble with gprof
try with oprof, but I would like some reassurance that we are not
slowing things down.

On 8 August 2011 13:06, Daniel Kraft <address@hidden> wrote:
> Basically, I'm thinking about an interactive command-line interface
> to explore the call-tree. (Later, we could also think about
> generating some output; like the Matlab HTML; or even
> gprof/callgrind data for use with those tools.)

The interactive interface is nice, but it's kinda nonstandard for
Octave core functions, and other than the demo functions, I can't
think of any other core Octave function that interactively requests
input from the user. This is not to mean this is undesirable, but
unusual. If you can do this easily (it's not too difficult to
implement this with m-scripts), go ahead, but don't lose sight of the
goal to also have access to this data non-interactively and
programmatically.

> How would you like hierarchical data presented?

How about nested cell arrays or cell structs? Look at how handle
graphics objects are nested, for example. That uses a lot of
references (handles), though, so perhaps this is not the best idea,
but I mean we have nesting structures that can represent the
hierarchy.

> Note that here again, I will seperate the backend from the interface
> -- i.e., make __profile_data or possibly a new function return the
> tree as Octave data structure, and have profshow.m interpret it and
> handle the interactive stuff. Thus, we can easily change the
> interface or add new presentation options.

Okay, I assume you will do this first?


2011/8/5 Daniel Kraft <address@hidden>:
> For now, I provide the attached patch (since it is still work in
> progress, I didn't commit it to my hg history and it's a raw patch;
> hope that's ok). It would be really cool if someone had an idea why
> is_defined() becomes false when I set the file-name. If not, I'll
> try to figure that out myself.

This is beyond my expertise, and it's one of the things I wish other
Octave developers can help us out with. So I hope someone else can
provide some insights here. The guts of the interpreter are something
I don't yet understand myself.

- Jordi G. H.