# Re: profiling

2 messages
 >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 
  > 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