Performance Baseline Tests¶

Use these tables as reference measurements for spatial queries, random generation, pooling and serialization. Profile your own workload before choosing an API for speed.

Baseline Philosophy¶

The baseline column is a generous time budget used to flag large changes. A failure needs investigation; device load, runtime changes and workload differences can affect the result. Passing the budget does not establish a speedup or a frame-time guarantee.

Test Categories¶

• Spatial Trees: QuadTree2D, KdTree2D, KdTree3D, OctTree3D, RTree2D construction and query performance
• PRNG: Random number generation throughput for PcgRandom, XoroShiroRandom, SplitMix64, RomuDuo
• Pooling: Collection pool rent/return overhead for List, HashSet, Dictionary, StringBuilder, SystemArrayPool
• Serialization: JSON and Protobuf serialization/deserialization throughput

Current benchmark measurements¶

No successful complete Unity Benchmarks run is available for publication yet. The committed measurements below are historical and are not results from the current candidate.

Read the measurements¶

The current measurements section identifies the measured package commit, Unity version, test mode and publication time when a complete run is available. Use those identities when comparing results with your project. The historical report below comes from an older run and cannot describe the performance of the current package on your device.

The package publishes complete benchmark results together with their raw test output. A partial or failed run leaves the last complete report in place. A published result can still show a regression: publication records the observation, rather than promising that every measured change is faster.

The separate comparison baseline currently contains no accepted metrics. Do not treat the tables as an accepted performance promise.

Historical performance baseline report¶

Generated: 2026-01-12 01:36:55 UTC

Spatial Trees¶

PRNG¶

Pooling¶

Serialization¶

Summary¶

19 passed, 7 failed out of 26 tests.

Running the Tests¶

Dispatch Unity Benchmarks to execute the current benchmark profile and publish its complete measurements to this guide. To inspect the historical baseline test report locally:

1. Open Unity Test Runner
2. Navigate to PerformanceBaselineTests
3. Run GeneratePerformanceBaselineReport explicitly (it is marked [Explicit])
4. Results are output to the console; they do not replace the committed current measurements

Interpreting Results¶

• Time (ms): Actual measured time for the operation
• Baseline (ms): Maximum allowed time before test failure
• % of Baseline: How much of the baseline budget was used (lower is better)
• Status: Pass if within baseline, Fail if exceeded

Refreshing these numbers¶

Run PerformanceBaselineTests.GeneratePerformanceBaselineReport from Unity's Test Runner.

Compare changes in your project¶

A baseline budget is a coarse regression check. It does not show that one implementation is faster than another. For that decision, compare both implementations in the same player with the same inputs, and check that they produce the same results before measuring them.

1. Choose representative inputs, including small, typical and peak sizes. Measure reads and writes separately when both matter to your game.
2. Warm each implementation before comparing steady-state work. Measure first use separately if startup latency matters.
3. Alternate measurement order and keep repeated samples. A single fast sample can reflect scheduling, garbage collection or an idle device rather than a useful improvement.
4. Include acquisition, clearing, conversions, useful work and cleanup in the measured operation. Measuring only an inner loop can miss the cost your caller actually pays.
5. Check allocation and retained memory separately from elapsed time. A warm operation can allocate nothing while keeping a large pooled buffer alive.
6. Repeat on the Unity versions, scripting backends and devices you ship. Editor, host, Mono, IL2CPP and WebGL results are not interchangeable.

If repeated samples are unstable, treat the comparison as inconclusive and investigate the measurement conditions. Do not report missing or unsupported memory counters as zero allocation. Include an operation known to allocate when checking that your allocation measurement works.

Understand paired reports¶

Some package benchmarks report calibrated, paired measurements alongside the simple tables. They warm both implementations, select a common iteration count, alternate measurement order and retain repeated samples. The reports include a throughput ratio, a confidence interval and sample spread.

A favorable timing report does not establish source compatibility, allocation cost, retained memory, startup cost or build size. Check the properties your application needs before adopting a change. See enumeration, pooled resource ownership and random generation for feature-specific choices and limits.