Re: profiling (was: Re: Octave Compiler)

[Przemek Klosowski]

   | - good facilities for profiling (to find the weak/slow spots) and
   |   debugging (NB, John, is there a way to instrument Octave to do a
   |   high-level equivalent of gprof? Would that be a good idea? It
   |   might simplify development work like fixing the concat slowness
   |   that you did recently)

   It would be possible to add some method of timing code to the
   interpreter.  How fine-grained should the profile be?  Function calls
   only or down to the individual statement level?  Should it only
   profile the interpreted code or should it also time compiled code
   (.oct files and built-in functions)?  At the level of compiled code,
   you would only be able to get timings per function call unless you
   actually compiled Octave for profiling and used the normal profiling
   tools.

I would imagine that finer would be better---per-statement for .m files and
per-function for .oct files. What would be a nice interface to it? perhaps
a structure, where field names identify functions, and the value is a 2D array
whose i-th elements are the count and cumulative time in the i-th line

      profile.sum(1,1)=1      first line of function 'sum' executed once
      profile.sum(1,2)=.05    .05 seconds spent in first line of function 'sum' 

How does that look? I have no idea how expensive would that be (e.g., would 
profiling
itself change the timing?); 

Should profiling be a command-line option, or should it be a runtime on-off 
option,
like tic and toc?