Re: First plans on a profiler

[John Swensen]

On May 25, 2011, at 10:33 AM, Daniel Kraft wrote:

> Hi John,
> 
> On 05/25/11 16:15, John Swensen wrote:
>> Isn't the profiler going to essentially be a modified tree_walker/executer?
> 
> first regarding the singleton discussion, I think both making it a singleton 
> and not doing so are possible options (for me) -- and it seems to me that it 
> shouldn't be too hard to convert if we later want to have multiple profilers 
> available sometime.
> 
> Regarding your statement above:  I don't yet know tree_walkers or executors 
> in octave, but as I understand it, the profiler class will rather be just the 
> one that keeps track of all the data and relates it to the call-tree or at 
> least list of functions; and finally later returns the profile-data in some 
> "useful" fashion.  The integration with tree-execution will be such that the 
> ordinary execution routines check a flag and if we're profiling make some 
> calls to the profiler-class to tell it when a particular function 
> enters/exits and the like.
> 
> Yours,
> Daniel

I don't know the right solution, but if a remember a mailing list discussion 
from the mailing list a while back, I thought the proposed solution for a 
profiler was to essentially have a "copy" of the existing tree walker evaluator 
with the added hooks of marking entry and exit from functions and computing the 
timing.  Maybe I misunderstood the conversation.  It seems the reason a 
completely separate,but nearly identical, evaluator was proposed was because we 
don't want to have to check a flag every step through the syntax tree to see if 
profiling is turned on as that would slow execution down.  Instead it would be 
an identical class plus some extra profiling code.

Like I said, I don't understand that part of the Octave code, I am just 
remembering a mailing list conversation that I can't find for the life of me 
(or I would link to it).

John Swensen