 |
lua-l archive |
|
|
||
|
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. In any case, tracing both Lua and LuaJIT with the same code is difficult, and hooks don't play well with jit.on.
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. 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.
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?
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.Are there any other alternatives or different approach to consider? How would one profile lua script performance under LuaJIT when lua C functions are involve?Mike mentioned profiling in the LuaJIT list in June: http://www.freelists.org/post/luajit/RFC-Lowoverhead-profiling-for-LuaJIT-21