-
-
Notifications
You must be signed in to change notification settings - Fork 292
Profiling features #551
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Profiling features #551
Conversation
…nd buffer and assignment logic Next up, prepare details from graphics.defineEffect()
…from Program Slight redesign of TimeTransform with caching (to synchronize multiple invocations with a frame) and slightly less heavyweight call site
Err, was calling Modulo for sine method, heh That said, time transform seems to work in basic test
Fixed error detection for positive number time transform inputs Relaxed amplitude positivity requirement
Maintenance Revert Test
My mistake adding back changes made
This reverts commit 0b5e1e9.
Some fixup in listener handling Added timing query stuff Had entirely forgotten to register the Lua functions :D
Some slight redesign of profiling classes Entries now reported afterward, not beforehand Added files to Windows project
Added sums for group:insert() and removal functions
Some slight redesign of profiling classes Entries now reported afterward, not beforehand Added files to Windows project
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome!
I will merge it after we make a build without it.
Note to self: Was adding files for another PR and saw there was also a |
It looks like these changes broke debugging. Now every error stack traceback points to error function in init.lua :
debug.getinfo returns same path So, handling "unhandledError" is completely useless now. The only thing that still works is event.errorMessage. Though it doesn't help if you have multiple nested functions. Looks like it's due to this rewrited part in init.lua
|
This adds some features to profile a running project.
At the moment, it has "Display" and "Render" sections, roughly corresponding to "update stuff" and "draw that stuff".
(Captures and hit events probably could use coverage but present some challenges.)
Basically, in each of those sections, several timestamps are taken—at each "significant" step along the way—and the deltas in microseconds are reported. There is some small sublist support too, allowing event listeners to be included.
The results can be obtained with
display.getTimings()
.There are some per-frame statistics that Solar itself can already gather. These can be enabled and analyzed via
display.enableStatistics()
anddisplay.getStatistics()
.There is also a
display.getSums()
function, although it's a no-op.Sums are similar to the timings described above, but they are meant for code that is hit numerous times, e.g. in a loop over child objects. The time differences are accumulated, and the number of visits recorded. (The counters are reset before rendering.)
These are disabled in normal code (
#define ENABLE_SUMMED_TIMINGS 0
) exactly because they're in some pretty hot spots, so will further impact code speed. (This was observed.) It would be interesting if some JIT techniques could be applied here. 😄They're mostly meant as a tool for engine development—whereas the other features are also meant for users—and have already flushed out some performance problems that I'll continue to pursue. The last bit is true of the other functions as well, and where some of these other PRs are coming from.
There are also some details about when these results happen (and therefore when you can query them) since your Lua code obviously occupies a point in time. 😃 I will try to expound on this in a later comment and docs.
Basic example:
I added
Rtt_Profiling.h
andRtt_Profiling.cpp
, so several files are projects with them added. I hope I got them all right. 😄