Add support for profiling system calls from GDScript with the tracy integration.
- Follow-up of #113279
- Implements the rest of https://github.com/godotengine/godot/pull/112707
Adds support for profiling system calls from GDScript:
The initial work has been done by @enetheru, although I ended up with a different implementation to theirs. The reason is that #112707 used the "rename" / "dynamic name" API, which leads to a lot of data leaks. As in the previous PR, that means that RAM quickly fills up when profiling. This PR doesn't leak large amounts of data, which means it should be possible to profile (almost) indefinitely.
Approach
This uses the implementation from #113279 to intern source location data. I just needed to add a few parameters to make it compatible with both.
For now, this implementation seems to be fast enough (very little overhead), though we need to keep an eye on it. If tracing starts slowing people's games down, there's a number of things we could do in the future:
- Add a compile time parameter for not tracing system calls
- Somehow improve the interning mechanism's speed
- Make the GDScript VM complicit in caching profile data, such that it can be retrieved during execution
I'm also not 100% sure that the approach of using e.g. methodname (the pointer the the StringName) is extremely robust, but I think the worst that could happen is misleading file names / lines for a particular system call.
Checking these two boxes fixes the line numbers! This should be documented, or perhaps the build env can 'fix' this automatically?
many functions show two zones in the profiler, an 'outer' and an 'inner'. Ideally these would be one zone, but this isn't a blocker for this PR in my opinion.
This is (unfortunately) expected.
The outer zone is the "caller" GDScript function. It is required to have this zone because it can show you the line number in the calling function (as long as debug/settings/gdscript/always_track_call_stacks is set to true). At this point, it's also not clear yet whether a GDScript function is called (which will lead to "duplicated" zones), or a system call (which won't).
The inner zone is the "callee", i.e. the called function. This zone is needed because it ensures calls from Godot to GDScript are profiled as expected. It also shows you the line number / file location of the called function. The difference between the two zones can be interpreted as the "call overhead".
It might be possible to make this just one zone, but this would probably be more complicated to implement.
Thanks!