[Update] November 30, 2022
Hi Developers,
We are excited to announce that we’re releasing a public beta of ScriptProfiler on Studio.
This is a new sampling profiler available as a tab within DevConsole. While running, this profiler records the entire call stack of all executing scripts with a sampling frequency of 1000 times per second.
To enable this beta feature, go to File → Beta Features, and select “Script Profiler”, then click Save, and restart Studio.
Using ScriptProfiler
Open DevConsole and navigate to the ScriptProfiler tab. Click the Start button to begin the profiling session. Click the button again to end profiling and display profiling data.
Profiling data is organized by top-level categories. Some categories correspond with specific sections of each of frame: Parallel Luau, WaitingScripts delayed threads, deferred threads, etc… Other categories correspond to events, such as RenderStepped.
By default, time spent in each node is represented as milliseconds of CPU time. Click Unit to toggle displaying time spent as percentages of the total recording session.
ScriptProfiler supports manually-specified profiler regions via debug.profilebegin()
and debug.profileend()
.
Hover your cursor over a node in the call-tree to view file and line information.
Switching to the Server tab enables profiling scripts running on the server. It is possible to profile both client-side and server-side simultaneously by switching between Client and Server. There may be a small delay between stopping the profiling session and updating the displayed profiling data.
Additional Notes
Currently, starting and stopping the profiler again will not reset the profiling data, instead, new profiling data will be aggregated with previously collected data.
While the profiler supports sampling Luau functions, and Roblox instance method calls and property access, time spent in standard library calls, or accessing primitive types, such as CFrame, will be attributed to the calling function.
Due to the nature of sampling, profiling data will be noisy for functions that don’t significantly contribute.
Threads that sleep, or wait, for results do not contribute to the overall time displayed by the profiler since they don’t consume CPU resources.
The profiling session initiated on a server is shared. The session will start when at least one user has started server-side profiling and will end when all users that have started server-side profiling on the same server have stopped profiling. This means that if a second user starts profiling while the profiler is already running on the server, the second user may receive profiling data that had been collected before they had started profiling.
Feedback
We are planning to release enhancements to this tool in the future. Feel free to suggest improvements, and report issues, in the thread below.
Thanks to @WallsAreForClimbing, @zeuxcg, and @machinamentum for working on this!