Performance Profiling

Versions with performance profiling

• 98699
• 98711
• 98809

These beta builds contain performance tools normally not available for a retail version. These builds will be a bit slower as a result, and is therefore not intended for a general use.

Scripting commands

• diag_captureFrame
• diag_captureSlowFrame
• diag_logSlowFrame

diag_captureFrame sample output

diag_captureFrame sample output

diag_captureFrame sample output

How to use

1. Run a mission
2. Execute a scripted command diag_captureSlowFrame ['total',0.3] using any means (DevCon, mission radio trigger...)
3. Once a slow frame is detected, a window will open.
4. In the window you will be able to browse a lot of interesting performance information, which can be interesting.
5. But the main thing you should do so that I can see the information as well is:
   1. Select Main Thread (if not selected yet)
   2. Press Copy button
   3. Open an external text editor
   4. Paste the text into a new file
   5. Save the file

Creating your own subtree

When Profiling Per-Frame Eventhandlers (PFH), diag_captureFrame only shows one blob called siFEH that contains all PFH's so you can't see what part of that is caused by your PFH.
You can create your own subtree inside siFEH by wrapping your function call inside a isNil CODE statement like this:
Turn your old call which may look like this: ["someId", "onEachFrame", myPFHFunction] call BIS_fnc_addStackedEventHandler; Into something like this ["someId", "onEachFrame", { isNil {call myPFHFunction} }] call BIS_fnc_addStackedEventHandler; Now when you run diag_captureFrame inside of siPFH you will have a subtree called gsEva and behind that you can see the first line of code inside the isNil statement.
It will only show a part of the first line of that code so you should put something descriptive into the isNil statement.
You can use the same to create a subtree for any function you like. This will also work inside Scheduled (spawned) scripts.
But using this method to "subtree" a function with return values requires a little bit of trickery to get the return value out.

diag_captureFrame sample output with custom subtree

Notes

• 0.3 is a time in second used to determine what duration of a frame you consider abnormal, and first such frame will be captured.
• 0.3 is definitely something you should not see in a normal game.
• If you do not capture any frames with 0.3, try lowering it to 0.2 or 0.1.
• If it triggers too early, before the main slowdown happens, increase it to a higher value, e.g. 1.0.

Read also

Scripting Code Optimization

Sources

• Comments by Suma