Performance Profiling: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
m (Text replacement - "\[ *(https?\:\/\/.+\.bistudio\.[^ ]+) ([^ ]+) *\]" to "{{ExternalLink|link= $1|text= $2}}")
(added link to branches page)
 
(14 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{TOC|side}}
== Versions with performance profiling ==
== Versions with performance profiling ==
The Profiling build is provided by Dwarden in tandem with the Performance build of Arma.
It can be found in the {{ExternalLink|link= https://forums.bistudio.com/forums/topic/160288-arma-3-stable-server-170-performance-binary-feedback/|text= BI Forum}} as well as in the ''#perf_prof_branch'' channel in the [https://discordapp.com/invite/0aWSevYPq5WJTWRK official Arma 3 Discord server]


'''Note''': Through the nature of a Profiling build they are not as performant as the normal release builds.
The Profiling build is provided by {{User|Dwarden}} in tandem with {{arma3}} [[Arma_3:_Steam_Branches|Performance build]].
It can be found in the {{Link|https://forums.bistudio.com/forums/topic/160288-arma-3-stable-server-170-performance-binary-feedback/|BI Forums}} as well as in the {{hl|#perf_prof_branch}} channel in the {{Link|https://discordapp.com/invite/arma|official {{arma3}} Discord server}}.


{{Feature|important|This work also with [[Arma 3: Diagnostics Exe]].}}
{{Feature|important|
* Through the nature of a Profiling build they are not as performant as the normal release builds!
* This work also with [[Arma 3: Diagnostics Exe]].
}}


== Scripting commands ==
 
[[File:Performance_Profiling_01.png|thumb|diag_captureFrame sample output]]
[[File:Performance_Profiling_02.png|thumb|diag_captureFrame sample output]]
[[File:Performance_Profiling_03.png|thumb|diag_captureFrame sample output]]
== Scripting Commands ==


* [[diag_captureFrame]]
* [[diag_captureFrame]]
* [[diag_captureSlowFrame]]
* [[diag_captureSlowFrame]]
* [[diag_logSlowFrame]]
* [[diag_logSlowFrame]] - not available in Arma 3 :(
* [[diag_captureFrameToFile]]


[[File:Performance_Profiling_01.png|thumb|diag_captureFrame sample output]] [[File:Performance_Profiling_02.png|thumb|diag_captureFrame sample output]] [[File:Performance_Profiling_03.png|thumb|diag_captureFrame sample output]]


== How to use ==  
== How to Use ==  


# Run a mission
# Run a mission
# Execute a scripted command <tt>[[diag_captureSlowFrame]] ['total',0.3];</tt> using any means ([[Arma 3 Debug Console|Debug Console]], mission radio trigger...)
# Execute a scripted command <sqf inline>diag_captureSlowFrame ["total", 0.3];</sqf> using any means ([[Arma 3: Debug Console|Debug Console]], mission radio trigger...)
# Once a slow frame is detected, a window will open.
# Once a slow frame is detected, a window will open
# In the window you will be able to browse a lot of interesting performance information, which can be interesting.
# In the window you will be able to browse a lot of performance-related data, which can be interesting
# But the main thing you should do so that I can see the information as well is:
# To export the gathered information for sharing with others:
## Select Main Thread (if not selected yet)
## Select Main Thread (if not selected yet)
## Press Copy button
## Press the Copy button
## Open an external text editor
## Open an external text editor
## Paste the text into a new file
## Paste the text into a new file
## Save the file
## Save the file


== Creating your own subtree ==
 
[[File:Performance_Profiling_04.png|thumb|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.<br>
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.<br>
You can create your own subtree inside siFEH by wrapping your function call inside a [[isNil]] CODE statement like this:<br>
You can create your own subtree inside siFEH by wrapping your function call inside a [[isNil]] CODE statement like this:<br>
Turn your old call which may look like this:
Turn your old call which may look like this:
<code>["someId", "onEachFrame", myPFHFunction] [[call]] [[BIS_fnc_addStackedEventHandler]];</code>
<sqf>
Into something like this
addMissionEventHandler ["EachFrame", {
<code>["someId", "onEachFrame", {
call myPFHFunction
isNil {call myPFHFunction}
}];
}] [[call]] [[BIS_fnc_addStackedEventHandler]];</code>
</sqf>
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.<br>
 
It will only show a part of the first line of that code so you should put something descriptive into the isNil statement.<br>
Into something like this:
<sqf>
addMissionEventHandler ["EachFrame", {
isNil { call myPFHFunction } // isNil creates the subtree
}];
</sqf>
 
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.<br>
It will only show a part of the first line of that code so you should put something descriptive into the [[isNil]] statement.<br>
You can use the same to create a subtree for any function you like. This will also work inside [[Scheduler#Scheduled_Environment|Scheduled]] ([[spawn]]ed) scripts. <br>
You can use the same to create a subtree for any function you like. This will also work inside [[Scheduler#Scheduled_Environment|Scheduled]] ([[spawn]]ed) scripts. <br>
But using this method to "subtree" a function with return values requires a little bit of trickery to get the return value out.
But using this method to "subtree" a function with return values requires a little bit of trickery to get the return value out.


[[File:Performance_Profiling_04.png|thumb|diag_captureFrame sample output with custom subtree]]


== Notes ==
== Notes ==
Line 52: Line 68:
* If it triggers too early, before the main slowdown happens, increase it to a higher value, e.g. 1.0.
* If it triggers too early, before the main slowdown happens, increase it to a higher value, e.g. 1.0.


== See also ==
 
[[Code Optimisation]]
== See Also ==
 
* [[Code Optimisation]]
* [[Mission Optimisation]]
 


[[Category:Arma Scripting Tutorials]]
[[Category:Arma Scripting Tutorials]]

Latest revision as of 17:18, 5 October 2024

Versions with performance profiling

The Profiling build is provided by Dwarden in tandem with Arma 3 Performance build. It can be found in the BI Forums as well as in the #perf_prof_branch channel in the official Arma 3 Discord server.

  • Through the nature of a Profiling build they are not as performant as the normal release builds!
  • This work also with Arma 3: Diagnostics Exe.


diag_captureFrame sample output
diag_captureFrame sample output
diag_captureFrame sample output

Scripting Commands


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


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