Add debug.profilebegin and debug.profileend about luau HOT 5 CLOSED

Here is an example for how this would be useful.
I have two pretty complex functions encode and parse. Dividing them up by lifting out small functions would require quite a bit of effort just for profiling sake, so I would have to repeat that if I were to update the functions.

This is how they currently look in flame graph and I would really like to get a better understanding on what is going on in that blank space when calling encode recursively:

from luau.

I looked at the profiler yesterday and its written completely in the CLI module, outside of the VM. The only thing it does in/to the VM is set the interrupt hook, and from there it reads the functions of the current stack. A very clean separation, I was impressed.

I think doing something like this requires a closer integration, and it might not be desireable to add profiling stuff to the now very clean VM module. It also can be troublesome to end the profiler scope on errors etc. A workaround might be to do selfcalling functions like

...code...
local function scopeName()
     ...code...
end()
...code...

from luau.

The other alternative is to write a 3rd party profiler lib that can add these functions, which I guess is whay they have done in roblox

from luau.

Silly but working thing I added to my test runner now to get scopes in the flame graph:

local scopeName = child.description:gsub("[^%w]", "_")
local namedScope = loadstring(string.format([[local function %s(callback, ...) return callback(...) end; return %s]], scopeName, scopeName), scopeName)()
namedScope(traverseContext, child)

traverseContext is a function I used to call straight up, now I call it through the scope function.

This little experiment did make me more motivated to fork the profiler and add useful stuff :) But the profiler is great, super fast 👌

from luau.

I'm going to close this since I don't think this will realistically happen.

It's possible to integrate debug.profilebegin/profileend with the sampling profiler - in fact, we're planning to do this in Roblox. However, it doesn't make debug.profile* easy to share and requires carrying extra per-thread state which not all embedders would appreciate. Additionally debug.profile* has some overhead so it's not a very good tool for profiling small sections of existing code - for that to work better, we'd need to improve the profiler to be able to collect perf data on a finer granularity (eg lines).

With the optimizer inlining at -O2 there's also now a possibility of refactoring the code to use more functions, and profiling at -O1 (and verifying, eg with the profiler, that the overhead disappears at -O2).

Either way this would effectively either require us to push debug. APIs into the core, or add more APIs that are REPL-only which we're trying to avoid to make the question "which library functions are present" more straightforward.

from luau.