Re: Octave profiler,

[Muthiah Annamalai]

> On 29-Jan-2007, David Bateman wrote:
> 
> | Not bad, but is this really the best place for the hooks to the
> | profiler? I'd have thought in the parser was better, though I don't know
> | where exactly to include the hooks as I'm not a YACC expert.. Doing it
> | in the parser would allow easier inclusion of code to get finer grained
> | profiling... I believe with the hook in the right place in the parser,
> | most of your existing code could easily be transitioned there without
> | much effort..

I refactored, the code, and shared common parts to get a call-graph
profiler working, very similar to the flat profiler. Call-graph
implementation follows in steps of Python. It is quite interesting to
look at the output, and possibilities in formatting the tree.

Also working on event filtering & time used (CPU, Real, and Process),
and some little details.

> On Mon, 2007-01-29 at 16:31 -0500, John W. Eaton wrote:
> 
> One possibility is to hook the profiler directly in to the eval,
> rvalue, etc. functions that are used to evaluate elements of the
> parse tree.  But then there could be a slight performance hit even
> when we are not doing profiling (all the eval functions have to check
> to see whether they should do the things necessary for profiling).
> 
> Another possibility is to write a profiling evaluator as a visitor
> class that works using the tree_walker structure.  It might actually
> be a useful experiment to see how hard it is to write an evaluator
> using this structure.  If it works and can be done with a minimal
> impact on performance, it would probably be better to have the
> evaluator written this way.  Then I think you might be able to write
> the profiling evaluator by deriving from the normal evaluator.  Then
> adding the profiling code to the interpreter would have no impact on
> the performance of the normal evaluator.
> 
> If this is possible, then a debugginng evaluator could be written the
> same way.  Instead, it is currently hooked in to the eval functions of
> the evaluator.
> 
> jwe

The latter option looks elegant, but like the fact that its
experimental. Also the resolution of events is important from many
points of profiling, and gives scope to provide a great tool for
introspecting Octave programs.

Also the new evaluator can enable the present system lose dead-weight
goo like.

                     if(profiler_is_active) { do_something }

I was having in mind, then two types (3, if you take debugger) of the
AST-walker objects must be there, and profiler can change the walker
used to evaluate the result, depending on user settings to the profile
command.

                    / [Debugging Evaluator] 
                   / 
                  x 
       [profiler] -- [Octave Evaluator]  --- > 
                  \ 
                   \                      
                    [Profiling Evaluator]
                                                   /---- [Flat Profiler]
                           | <event_hook>         /
                           +------------------> < |----- [Graph Prof']
                                                  \
                                                   \---- [Turbo* Prof' ]

Only that when user chooses a profiler-walker, it is capable to
providing events to the callback/hooks. The design looks good, I am also
going to have to look on the inside of other event-hook implementations
that deliver the profiler events.

-Muthiah