Re: First plans on a profiler

[Daniel Kraft]

Hi,

thanks for your comprehensive answer!  This should really help me get 
off with the first experiments, I think.

On 05/24/11 20:01, John W. Eaton wrote:
> So you will most likely have to modify the functions
>
>    octave_user_script::do_multi_index_op
>    octave_user_function::do_multi_index_op
>
> in ov-usr-fcn.cc for user-defined scripts and functions,
>
>    octave_builtin::do_multi_index_op
>
> in ov-builtin.cc for built-in functions and functions defined in .oct
> files (they are both handled as "built-in" functions because they are
> called in the same way even though .oct files are dynamically loaded),
> and
>
>    octave_mex_function::do_multi_index_op
>
> in ov-mex-fcn.cc for functions defined in MEX files (these are handled
> separately because the calling conventions are different from built-in
> functions and functions defined in .oct files).

Ok, that makes sense and was what I was looking for -- thanks!

> Anonymous functions are just user-defined functions, so they will be
> handled by the octave_user_function class, but you will need some way
> of distinguishing each anonymous function so you can properly report
> the timings for each one separately.  For example, you'll probably
> want to be able to report the timing for "anonymous function defined
> in FILE at line L, column C".

Yes, there we probably have to think something up -- but that's more or 
less "interface" stuff and won't affect the way data collection works 
behind the scenes, right?

> I don't know how best to record the timings, but here is an possible
> way:
>
>    * Define a class profile_data_accumulator.  This class should
>      probably be a singleton object since we likely only want one
>      profiler at a time to be active and using a singleton helps to
>      avoid initialization problems.  There are other singleton objects
>      in Octave and they all use a similar style, so it would be best to
>      follow the style of the others.

I was thinking about something similar -- and thanks for the hint with 
the already existing singletons, I'll then try to mimic their style of 
course.

Just one thought I also had:  Do we possibly want to allow for multiple 
profiler objects the user also has access to, like via Octave's OOP 
interface?  So that he/she could have profilers in parallel and 
accumulate data on each of them based on the needs?  I can't think of a 
situation when that would be really useful, though.  So probably the 
singleton is just fine.  (And it should not be too hard to change that 
later if we really would want to have multiple profilers possible.)

>    * The profile_data_accumulator class should have a function that
>      checks the CPU timer and stores timestamp date somehow.  I think
>      something like
>
>        void
>        profile_data_accumulator::do_timestamp (octave_function&  fcn)
>
>      should work because all the octave_X function class objects listed
>      above are derived from the octave_function class, and so you
>      should be able to get all the info about a function object that is
>      required to uniquely identify it from the octave_function object
>      (or through virtual functions that will dispatch to the derived
>      objects to get you specific information about the individual
>      classes).
>
>      The do_timestamp function is called, it can get the current CPU
>      time info and it should know the previous value as well.  This
>      chunk of time should be applied to the currently profiled function
>      and then the function which was given as an argument will become
>      the current function and the current CPU time info can be
>      updated.  I think the results can be stored in a simple map that
>      allows lookup from a full function name (complete file name for
>      .m, .oct, .mex files, something like builtin:NAME for actual
>      built-in functions, command-line:NAME for functions defined on the
>      command line, and perhaps anonymous:LINE:COLUMN for anonymous
>      functions).

Sounds good, although I was probably more thinking about something like:

void
profile_data_accumulator::enter_function (const octave_function& fcn)

void
profile_data_accumulator::exit_function (const octave_function& fcn)

This way, we can build up a complete call tree (at least at a later 
stage if we want hierarchical profile data, which has proven really 
useful to me at times instead of just a flat profile).

Is it ok to "identify" the functions internally via their address (i.e., 
&fcn)?  Or could that change during the course of profiling (when 
reloading from file?) or the other way round, could there be two 
"different" objects representing the same function?  Or should I use 
strings based on the names just as you suggest above?  (Of course, for 
printing the result, we always go back to a name, obviously...)

> As for displaying the data and controlling the profiler (turning it on
> or off or whatever), I think we should have a "profile" function that
> is compatible with the one in Matlab since that is what people using
> Octave will expect.  It would be nice, but not essential, to have a
> profsave function that does something functionally equivalent, but I
> don't think it is necessary to generate precisely the same HTML...

Ah, I was not aware that there exists already such a command-line 
interface (it seems) to the profiler in Matlab -- then of course I agree 
that we should try to mimic that interface as far as practical, and will 
try to inform me about how this function works (I've never used it).

But I think the first things I'm going to do is data collection with 
some hacked output routines; then we can work on the interface later.

BTW, I still believe that it could be a good idea to have a C++ function 
return the profile-data as some Octave structure with certain format 
internally, but then implement the semantics of profile, profsave or 
whatever in .m files.  Does this sound like a good idea?

> One thing I'm not sure about is what to do with recursive function
> calls.  How do profilers normally handle that?  Is the time for all
> recursive calls (to the same function) lumped together, or are they
> stored separately somehow?
>
> Another is how to handle the call graph, if that is information that
> needs to be stored.

I think I'll try to implement at least the interface to the profiler 
class as above which in theory provides all information about call-graph 
and recursion, and then experiment with different storage and of course 
user-interface formats.  Probably also start with a very basic, flat 
profile and extend that later to support more features over time.

> In any case, does the above outline of a way to attack this problem
> sound like it would work?  I'm not sure of all the details and have
> not given it a lot of thought, so please follow up here if there is
> something above that is not clear, seems wrong, or appears to be
> mising.

Yes, I really think this sounds reasonable -- and also should give me 
some first pointers for where to start hacking the source.  (But I've 
not yet tried anything or looked at that code myself so far.)  Thanks a lot!

Yours,
Daniel

--
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri