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:46:23 -0400

On 25-May-2011, John Swensen wrote:

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

That was my original plan for both profiling and debugging, but it
turns out that it is not really useful since deriving a new debugging
(or profiling) evaluator from the normal evaluator does not help
much.  You end up duplicating the whole thing.  Since there are only a
few places where you need checks like

  if (debugging)
    do_something ();

and checking a bool variable is very low cost, it doesn't really slow
down the interpreter in any significant way.  Adding a similar check
for profiling will not cause any noticeable change in the interpreter
speed (it will still be slow, but not slower in any measurable way).

Additionally, if you have separate tree walkers, you can't enable
debugging and profiling at the same time without having a
debugging+profiling evaluator.  Or at least, I could not see how to do
it using separate derived classes.

jwe


reply via email to

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