R3vo/Sandbox – User

If you have ever wondered why you scenario is running so badly, performance profiling is the way to find it out. It allows you to find bottlenecks and slow code by capturing a "slow" frame. The captured data can then be viewed and analysed.

Getting the correct Version

Profiling is enabled in the following Arma 3 versions

• arma3profiling_x64.exe - Part of the Performance Profiling Build
• arma3diag_x64.exe - Part of the Development Build

Read Arma_3: Steam Branches for a guide on how to access these branches.

ⓘ

It is recommended to use the Performance Profiling Build (arma3profiling_x64.exe) for performance profiling because:

• Has tools that might not make it into development build
• Has all the profiling related commands that arma3diag_x64.exe has
• Its performance is closer to the default arma3_x64.exe

Frame Capturing

There are several commands that allow you to capture a frame.

• diag_captureFrame
• diag_captureSlowFrame
• diag_logSlowFrame - not available in Arma 3 :(
• diag_captureFrameToFile

In most cases you do not want to capture any or all frames, you just want to capture "slow" frames. A slow frame is a frame that takes longer than the average frame and slows down the game.

How to Use

1. Run a mission
2. Execute a scripted command diag_captureSlowFrame ["total", 0.3]; using any means (Debug Console, 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 performance-related data, which can be interesting
5. To export the gathered information for sharing with others:
   1. Select Main Thread (if not selected yet)
   2. Press the Copy button
   3. Open an external text editor
   4. Paste the text into a new file
   5. Save the file

Capture Frame UI

1. 🚧

   TODO: this must be updated.
2. 🚧

   TODO: this must be updated.
3. 🚧

   TODO: this must be updated.
4. 🚧

   TODO: this must be updated.
5. 🚧

   TODO: this must be updated.
6. 🚧

   TODO: this must be updated.
7. 🚧

   TODO: this must be updated.
8. 🚧

   TODO: this must be updated.
9. 🚧

   TODO: this must be updated.

diag_captureFrame sample output with custom subtree

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:

addMissionEventHandler ["EachFrame", { call myPFHFunction }];

Into something like this:

addMissionEventHandler ["EachFrame", { isNil { call myPFHFunction } // isNil creates the subtree }];

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.

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.

See Also

• Code Optimisation
• Mission Optimisation