octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: First plans on a profiler


From: John W. Eaton
Subject: Re: First plans on a profiler
Date: Wed, 25 May 2011 11:33:06 -0400

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.

| 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?

| 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.

| 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?)

Yes, if a function is reloaded, the object will change.  But that
should not be happening during a call to the do_multi_index_op
function that handles the evaluation of a given function object.

But if you are thinking of deferring the work of caching the file
names when you are collecting data and then only look those details up
later when you report profiling info, I think you will be in trouble
because then it would be likely that the pointers you stored would no
longer be valid.

| or the other way round, could there be two 
| "different" objects representing the same function?

No, that should not happen.

| 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...)

That's what I think would be best.  If necessary, we can construct
names appropriate for the profiler once, when the function is parsed
to avoid extra work each time they are needed.  We already cache the
full name of the file where the function was found, and line and
column information, so it would be easy to add another method to the
octave_function class that gives you the unique name of a function
that can be used as a key in your profiling data map.  Copying a C++
std::string object as a key in a std::map object should be fast.

| 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?

Yes.

| 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.

OK.

| > 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!

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

Thanks,

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]