[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave profiler,
From: |
Muthiah Annamalai |
Subject: |
Re: Octave profiler, |
Date: |
Tue, 30 Jan 2007 09:51:43 -0600 |
> 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