Implementation of a profiler

[Daniel Kraft]

Hi all,

in January, I already posted with respect to a possible project to get 
me working on Octave (and maybe in the frame of Google Summer of Code). 
 See
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-January/022004.html.

Now, I think the most interesting project for me would be to work on a 
profiler.  Especially, since that is what would have been most useful to 
me as a user myself; and it also seems interesting to me.

I'm not sure when I will really have time to work on that, but my plan 
would be over the coming half year or so.  And I'll just write down some 
ideas here, and would be very interested to get your opinions with 
respect to them and work on a profiler in general (does it seem useful, 
doable and "good" the way I plan it?).

Admittedly, I have not yet looked at Octave's source code (further than 
checking out a hg repository).  But I suppose there's some kind of 
abstract syntax tree modelled by C++ classes that is generated by the 
parser and then used to evaluate different kinds of statements, 
expressions and the like.  For a profiler, my idea is to add code there 
that collects statistics like number of times something is 
evaluated/executed and the time needed for that.  This should be more or 
less straight-forward, and when that is done, some kind of UI (on the 
command-line similarly to gprof, for instance) can present the results.

However, I see two (possible) problems:

1) Collecting run-time for each statement may not work, because the 
overhead and/or resolution calling whatever timing routine is used (like 
gettimeofday for GNU/Linux) may be inacceptable for the time it takes to 
actually execute the statement (if that is too fast).  I don't know 
whether that would be a real problem or not; if we find out that it is, 
one could restrict timing to function calls (as gprof does) or possibly 
also loops and larger "blocks" of code.  (Or determine that at run-time 
dynamically, i.e., don't do any further timing when earlier timings were 
not useful.)

2) Also depending on how much overhead there is in statement-evaluation, 
there will of course be additional cost for the profiling code.  So 
either it is "not significant" (especially if we restrict it to whole 
functions), or I have to find a way to switch profiling on/off without 
*any* costs if disabled.  This probably depends on the Octave code, but 
one "a priori" idea is to have to versions of "evaluator classes" 
(possibly by templates with a boolean template parameter).

What do you think?  Does this sound somewhat reasonable?  Would it be a 
candidate for a useful Summer of Code project, too?  Any other problems 
(or solutions to problems)?  I really hope that in the end I can provide 
something useful to Octave and its users.

Yours,
Daniel

PS: I guess that the usual FSF paperwork applies to Octave, right?  I do 
have copyright assignments for GNU Guile and GCC, but probably have to 
submit a new form in case I finally have some code to submit to Octave 
in the end.

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