Performance Profiling: Difference between revisions
Lou Montana (talk | contribs) m (Text replacement - "<code>" to "<code style="display: block">") |
Lou Montana (talk | contribs) m (Some wiki formatting) |
||
Line 1: | Line 1: | ||
{{TOC|side}} | |||
== Versions with performance profiling == | == Versions with performance profiling == | ||
The Profiling build is provided by {{User|Dwarden}} in tandem with {{arma3}} 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 Forum}} as well as in the {{hl|#perf_prof_branch}} channel in the [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 | |||
[[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]] | ||
Line 13: | Line 21: | ||
* [[diag_logSlowFrame]] | * [[diag_logSlowFrame]] | ||
== How to | == How to Use == | ||
# Run a mission | # Run a mission | ||
Line 28: | Line 35: | ||
## Save the file | ## Save the file | ||
== Creating | |||
[[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: | ||
< | <sqf> | ||
Into something like this | ["someId", "onEachFrame", myPFHFunction] call BIS_fnc_addStackedEventHandler; | ||
< | </sqf> | ||
isNil {call myPFHFunction} | |||
}] | Into something like this: | ||
<sqf> | |||
["someId", "onEachFrame", { | |||
isNil { call myPFHFunction } | |||
}] call BIS_fnc_addStackedEventHandler; | |||
</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> | 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> | It will only show a part of the first line of that code so you should put something descriptive into the isNil statement.<br> | ||
Line 43: | Line 58: | ||
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. | ||
== Notes == | == Notes == | ||
Line 52: | Line 66: | ||
* 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 | |||
[[Code Optimisation]] | == See Also == | ||
* [[Code Optimisation]] | |||
* [[Mission Optimisation]] | |||
[[Category:Arma Scripting Tutorials]] | [[Category:Arma Scripting Tutorials]] |
Revision as of 14:33, 20 March 2023
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 Forum as well as in the #perf_prof_branch channel in the official Arma 3 Discord server
Scripting Commands
How to Use
- Run a mission
- Execute a scripted command diag_captureSlowFrame ['total',0.3]; using any means (Debug Console, mission radio trigger...)
- 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.
- But the main thing you should do so that I can see the information as well is:
- Select Main Thread (if not selected yet)
- Press Copy button
- Open an external text editor
- Paste the text into a new file
- 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:
Into something like this:
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.