Re: First plans on a profiler

[Daniel Kraft]

On 05/25/11 17:33, John W. Eaton wrote:
> On 25-May-2011, Daniel Kraft wrote:
>
> | On 05/24/11 20:01, John W. Eaton wrote:
> |>  So you will most likely have to modify the functions
> |>
> |>  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'm not sure exactly what you mean here.  I don't think you want to
> use pointers to internal data structures as the index to profiling
> data, even for internal data collection, so you have to decide how to
> name the anonymous functions.  Using file+line+column where the
> anonymous function is defined seems like a reasonable solution to me,
> as that should be unique.  Similarly, I think you will need some kind of
> notation for subfunctions, but there is already some precedence for
> those.  For example, dbstop allows setting a breakpoint at
> main>subfunction  So maybe the map key for subfunctions could use the
> full name of the file that contains the subfunction with
> ">subfunction-name" appended.

(Taking this together with some answers you provided below.)

Yes, actually I was thinking about using the pointer as index into the 
map -- if it were something identifying the function uniquely, I would 
have seen no reason for why I didn't want to do that.  But of course if 
reload may change the address or the function may go out of scope and be 
discarded during profiling (not just a single do_multi_index_op call!), 
then using the strings as keys is probably best.

And I also think we should add a new method to the function class, just 
like you suggested.

> | 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.)
>
> When or how would multiple profilers be active at the same time?

I was thinking about a situation like this:

do_profiling ('profiler_a', something_belonging_to_task_a ());
do_profiling ('profiler_b', something_for_task_b ());
do_profiling ('profiler_a', something_more_for_a ());

report_profile ('profiler_a');
report_profile ('profiler_b');

(Or the like.)  I can't think of a real situation where this may 
actually be useful, but I just thought we may find one in the future -- 
and I think that it shouldn't be too hard to make the profiler class 
work even as non-singleton.  (I'll just write some code and try things 
out, I guess.)

> | 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).
>
> OK, so you need to call enter_function at the beginning of the
> "do_multi_index_op" methods and then call exit_function before
> returning.  But to ensure that the exit_function call happens no
> matter how the function exit occurs (could be because of an
> interrupt), I think you will have to do this by registering a call to
> it with an unwind_protect object.

Exactly -- for the first try, I'll probably just do this and then try to 
get the unwind_protect stuff work.

> Please don't hesitate to ask questions if you get stuck or are
> confused by some internals.

Thanks!  And I'll do, of course!  Unfortunately, I'll not have too much 
time still, so I don't know when I actually can code some first things 
up -- but anyway I'll ask if I have any problems.

Yours,
Daniel

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