lua-users home
lua-l archive

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

On 4/09/2013, at 3:14 PM, wrote:

>> I thought I'd got that one right at least, but it's been a while since I worked on or used luatrace I don't really remember.
> Thanks for the response. I only tried luatrace briefly but it does seem to track call times for C functions correctly. Unfortunately, it doesn't seem to be very usable in its current state. For example, there's too much of a performance hit when tracing is turned on.

Hooks are slow.  Try 
time lua -e "for i = 1, 10000000 do end"
time lua -e "debug.sethook(function() end, 'crl') for i = 1, 10000000 do end"

C hooks are a little better, but really, anything hook-based is going to be problematic.

> It also generates a massive amount of information that isn't really viewable as is. There's a lot of non-critical data dumped into the trace file that simple isn't relevant to optimizing the program at hand and weeding all of that out is a lot of work.

I don't know what your program is or what data is or isn't relevant to optimising your program.  If it helps you can turn luatrace on or off for sections of your program.

The trace file contains timings for every line that's traced, so I don't see that as irrelevant to general profiling (if you want a line-by-line profiler).  Are you actually looking at the trace file or the annotated source?  You could try lua -luatrace.profile and avoid the intermediate file.

> Is there someway to reduce the amount of 'noise' luatrace records or even better, have some kind of sampling mode that grabs the callstack on some specified frequency?

No.  Luatrace is a line-by-line profiler rather than a sampling profiler.  Sampling profilers are available though (not sure which ones).  One of the problems with a sampling profiler you can't accurately reconstruct a call stack in the presence of tail recursion.  Luatrace does quite a bit of work to (try to) catch tail returns, but to do so, it needs to check every line.  I think you might find sampling profilers won't ever catch any time in C functions either.

>> Mike mentioned profiling in the LuaJIT list in June:
> I did read through that thread and the impression I got was that it's still under development and it's unclear to me what its current status is. For example, are the primitive underlying constructs and tools needed to develop a profiler in place and stable? The thread itself is way back in June but I haven't found other threads about profiling since then.

It's probably best to ask on the LuaJIT list.