|
|
| (28 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| {{TOC|side}}
| | = Mobile To-Do = |
| 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.
| | ''A list of things that would improve mobile compatibility'' |
| The captured data can then be viewed and analysed.
| |
|
| |
|
| == Getting the correct Version ==
| |
| Profiling is enabled in the following {{arma3}} 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.
| | ''Lou thinks just because the list is empty there is nothing left to improve. Only if he knew.'' |
|
| |
|
| {{Feature|informative|It is recommended to use the '''Performance Profiling Build''' (arma3profiling_x64.exe) for performance profiling because:
| | = Done = |
| * 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''}}
| |
|
| |
|
| [[File:Performance_Profiling_01.png|thumb|diag_captureFrame sample output]]
| | * Creator dlc template needs a noresize. |
| [[File:Performance_Profiling_02.png|thumb|diag_captureFrame sample output]]
| | ** {{Link|Spearhead_1944}} |
| [[File:Performance_Profiling_03.png|thumb|diag_captureFrame sample output]]
| | * Long command names should wrap |
| | ** {{Link|removeAllUserActionEventHandlers}} |
|
| |
|
| == Frame Capturing ==
| | * See also entries on command and function pages are broken |
| There are several commands that allow you to capture a frame.
| | ** {{Link|parsingNamespace}} |
| * [[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 ==
| | * Command and function template layout wastes a lot of space due to the two column design |
|
| |
|
| # Run a mission
| | * Tables with fixed widths need to be avoided. If they are too wide use noresize class wrapper |
| # Execute a scripted command <sqf inline>diag_captureSlowFrame ["total", 0.3];</sqf> using any means ([[Arma 3: Debug Console|Debug Console]], mission radio trigger...)
| | ** {{Link|Arma_3:_Visual_Upgrade}} |
| # Once a slow frame is detected, a window will open
| |
| # In the window you will be able to browse a lot of performance-related data, which can be interesting
| |
| # To export the gathered information for sharing with others:
| |
| ## Select Main Thread (if not selected yet)
| |
| ## Press the Copy button
| |
| ## Open an external text editor
| |
| ## Paste the text into a new file
| |
| ## Save the file
| |
|
| |
|
| | | * YouTube embeds and images should not have a fixed width |
| [[File:Performance_Profiling_04.png|thumb|diag_captureFrame sample output with custom subtree]]
| | ** {{Link|Category:DayZ}} |
| == Creating Your Own Subtree ==
| | ** {{Link|Spearhead_1944_Frontline_Function}} |
| | | ** It is because the youtube template has a hardcoded minimum width. This should get removed |
| 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>
| |
| Turn your old call which may look like this:
| |
| <sqf>
| |
| addMissionEventHandler ["EachFrame", {
| |
| call myPFHFunction
| |
| }]; | |
| </sqf>
| |
| | |
| 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>
| |
| 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]]
| |
| | |
| | |
| [[Category:Arma Scripting Tutorials]]
| |
