octave-maintainers
[Top][All Lists]
Advanced

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

First plans on a profiler


From: Daniel Kraft
Subject: First plans on a profiler
Date: Sat, 21 May 2011 10:33:34 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9

Hi all,

here are some first thoughts on implementing the profiler; so far I've not yet tried to actually hack together something based on them, but welcome any comments! (As you of course know the internal working of Octave by far better than I do.)

At first, I would like to experiment with exact profiling on the level of functions. For this, I would like to measure the time spent in each individual function -- possibly by doing something like (just as kind of "pseudo-code" of course):

function bar ()
  time = 0;
  start = cputime ();

  ... some code ...

  end = cputime ();
  time = time + (end - start);
  bar ();
  start = cputime ();

  ... some more code ...

  end = cputime ();
  time = time + (end - start);
end

And keeping track of "own" time for each function this way. We'll see then by experiment whether this gives acceptable performance and whether the resolution of the timer is well enough to make this feasible.

Note that we probably even have to do the timing with unwind_protect (or rather some equivalent handling directly in the interpreter of course) in order to ensure correct working even in the presence of errors thrown.

I tried a quick search of the octave's pt-* code but wasn't able to find where function calls are made or which structures represent functions defined in .m files. (I found fct-handle, but am not sure whether this is actually really involved when calling any function or only for stuff like anonymous functions or doing foo = @bar?)

Do you think we should store timing information directly in the function object in the syntax tree? I thought so first, but then it came to my mind that with that, it would possibly be harder to iterate over all functions called during the last profiling session to get the output together and clear the times when necessary... So an alternative would be to have a seperate "profiler" class store all the data in some kind of map which includes all functions as keys (either hashed on the function name or the pointer to the function object). What do you think there?

I'm really looking forward to trying my luck on this! :)  Yours,
Daniel

PS: I won't have access to my mails over the weekend, but can come back to your replies on Sunday evening or Monday.

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


reply via email to

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