[Top][All Lists]

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

Implementation of a profiler

From: Daniel Kraft
Subject: Implementation of a profiler
Date: Tue, 01 Mar 2011 11:58:35 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7

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

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.


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.

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]