Re: profiling

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: profiling

Luiz Henrique de Figueiredo
>From [hidden email] Mon Jun 22 23:15:08 1998
>
>On Mon, Jun 22, 1998 at 10:51:51PM -0300, Norman Ramsey wrote:
>> Speaking of this problem, are there any profiling tools that help
>> identify hot spots in Lua code?
>
>It would be really easy to strap on something which would gather
>statistics about how many times a particular address/function was run.
>This wouldn't give you timing information, but it would be half way there.
>In fact, it could be done with the debugging interface.

In fact, this is the way to do it.  To quote the reference manual:

   Lua has no built-in debugging facilities.  Instead, it offers a special
   interface, by means of functions and \emph{hooks}, which allows the
   construction of different kinds of debuggers, profilers, and other
   tools that need ``inside information'' from the interpreter.

>Likewise, it should be easy to make a function profiler which uses the
>debugging interface to time the amount of time spent in a function.

it is easy, but not necessarily useful, because the time required for calling
the function may be of the same order of magnitude as the time spent in it,
unless the function really does a lot, in which case it is probably badly
written ;-)
seriously now, my point is that profiling an interpreted language is harder
than profiling C.
profiling times taken on each line is almost certainly misleading because
of overhead. profiling times taken in functions might be ok.
what is equally easy and much more "correct" and probably just as useful
is a report that includes just the number of times each line is executed.

i have done some preliminary work on a profiling library but did not finish
it in time for 3.1. right now, we're working on releasing 3.1 real soon.
after 3.1 is out, i'll go back to this, if there's enough interest.

>(can you trap on a return?)

yes. again, from the reference manual:

  typedef void (*lua_CHFunction) (lua_Function func, char *file, int line);
...
  when leaving a function,
  |func| is |LUA_NOOBJECT|, |file| is |"(return)"|, and |line| is 0.


--lhf

Reply | Threaded
Open this post in threaded view
|

Re: profiling

Norman Ramsey-3
 > seriously now, my point is that profiling an interpreted language is harder
 > than profiling C.
 > profiling times taken on each line is almost certainly misleading because
 > of overhead. profiling times taken in functions might be ok.

What I'd like to do is simulate gprof, i.e., simply record the call
stack at timer interrupts and sort out the mess later.  What I can't
figure out, however, is an easy way to figure out the proper
interleaving of the Lua and C stacks.  If I take an interrupt, which C
functions should be profiled for themselves, and which should be
charged to the account of lua_stackedfunction(0)?


Norman