# Collecting performance data

## In this learning path

- [Introduction](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/)
- [Set up](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/1-setup/)
- [Arm Neon and the Unity Burst compiler](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/2-arm-neon/)
- [The sample project](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/3-sample-project/)
- [The plain (unoptimized) code](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/4-the-code/)
- [The optimizations](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/5-the-optimizations/)
- [Collecting performance data](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/6-collecting-performance-data/)
- [Analyzing the performance data](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/7-analyzing/)
- [Profiling best practice](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/8-best-practice/)
- [Summary](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/9-summary/)
- [Appendix](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/10-appendix/)
- [Next Steps](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/_next-steps/)

## Measure and compare
As with any typical software development, once you have reached an optimization cycle, you will want to measure existing performance, make modifications to code, structures or data and then measure again and compare the results.

To keep this learning path a reasonable length, we will just measure and compare the final optimized versions against the original. We’ll collect data for plain, Burst and neon modes. This section will cover this using the Profiler and Analyzer tools in Unity.

For more detail regarding the Profiler and Analyzer, please read the previous learning path in this series, [Profiling Unity apps on Android](https://learn.arm.com/learning-paths/mobile-graphics-and-gaming/profiling-unity-apps-on-android/).

## Create a consistent scenario
First, you will need a consistent scenario in which you can reliably compare the three modes. We need to compare the data when all the versions are processing the same amount of data. It’s important to note that the randomness of the scene can make it harder to pick representative frames but we can wait until the number of characters is the same in each run.

The sample generates new characters every frame up to a maximum of 2401. This maximum is reached in a couple of minutes or so.

Unfortunately, the sample code in the CollisionCalculationScript doesn’t display the character count but it can be added easily.

### Display character count
First, pass the character count to the `ScreenWriteout` function call in *Update*. Line 265 becomes:

```csharp
ScreenWriteout(numChar);
```

Now add the `numChar` parameter to the function. Line 497 becomes:

```csharp
private void ScreenWriteout(int numChar)
```

Now display the character count in the `ScreenWriteout` function. Lines 506 and 507 become:

```csharp
+ "Character Collisions: " + radiusCollideFrameTime().ToString("N3") + "ms\n"
+ "Characters: " + numChar.ToString();
```

## Record performance data for plain mode
You will need to ensure plain (unoptimized) mode is active:
1. Open *Assets/BurstNeonCollisions/Scripts/CollisionCalculationScript.cs*
2. Go to line 66
3. Edit the line to match the following:

```csharp
public const Mode codeMode = Mode.Plain;
```
4. Open *Build Profiles* from the *File* menu
5. Ensure the following options:
   - *Development build* is ticked
   - *Autoconnect Profiler* is ticked
   - *Run Device* is set to your Android device
6. Select *Build and Run*
7. Choose a filename, e.g., *plain.apk*
8. The application will build and deploy to your Android device
9. The Profiler will start collecting data automatically
10. Wait until the character count hits 2401 and then make sure to record for another 300 frames. If you prefer, you could clear the results as soon as the character count hits 2401, or not tick *Autoconnect Profiler* and start recording manually.
11. Select the disk icon in the top-right and save the data as *plain.data*

## Record performance data for Burst mode
Repeat the above process to record performance data for Burst mode. All of the steps are the same except that we set the mode in *CollisionCalculationScript.cs* as follows:

```csharp
public const Mode codeMode = Mode.Burst;
```

Name your apk *burst.apk* and your saved performance data as *burst.data*.

## Record performance data for Neon mode
Repeat the above process again to record performance data for Neon mode. Again, the steps are the same except that we set the mode in *CollisionCalculationScript.cs* as follows:

```csharp
public const Mode codeMode = Mode.Neon;
```

Name your apk *neon.apk* and your saved performance data as *neon.data*.