This document is about: QUANTUM 3

SWITCH TO

QUANTUM 1 QUANTUM 2 QUANTUM 3

Quantum Profiler Explained: Finding Real Performance Bottlenecks

This page accompanies the Photon Quantum Profiler Explained: Find Real Performance Bottlenecks video and explains how to measure Quantum performance correctly, read Graph Profiler metrics, inspect custom workload spikes, and identify real bottlenecks with Unity and Quantum profiling tools.

Use this page when you want to verify whether an optimization actually improves runtime performance, or when you need to understand where simulation, rendering, script, or networking costs are coming from.

Photon Quantum Profiler Explained: Find Real Performance Bottlenecks

Overview

Performance optimization should be measured in a representative runtime setup.

Before changing systems, simulation settings, or workload distribution, use profiling data to confirm the actual bottleneck. Debug builds, checksums, editor overhead, and artificial test conditions can distort measurements and lead to incorrect conclusions.

This video covers:

how to prepare a Quantum project for profiling;
why Quantum Release builds matter;
how to add and read the Quantum Graph Profiler;
how Physics Sleeping affects simulation performance;
what each Graph Profiler entry means;
how local simulations differ from online simulations in profiler output;
how to simulate degraded network conditions;
how to use custom profiler markers;
how to inspect marked code in the Unity Profiler;
how to use the Quantum Task Profiler;
when Remote Profiling is useful.

Video Timeline

Time	Section
00:00	Introduction
00:21	Recommended performance analysis setup
00:59	Adding Graph Profiler
01:17	Performance with and without sleeping enabled
01:52	Graph Profiler entries
04:11	Offline graph entries
04:19	Simulating bad network state
04:37	Toggling graph entries on and off
04:52	Profiler System
05:07	Custom marker
05:12	Testing the Profiler System with heavy workload
05:40	Modifying the workload interval
06:20	`HostProfiler` to Unity Profiler
06:46	Quantum Task Profiler
07:18	Remote Profiling

Recommended Profiling Setup

For reliable performance analysis, profile the project in a production-like configuration.

Use:

Quantum Release DLLs;
an IL2CPP Unity build;
the Quantum Graph Profiler;
representative gameplay scenarios;
stable test conditions across comparison runs.

To switch Quantum DLLs to Release mode, use:

Tools > Quantum > Toggle Debug DLLs > Release

Release builds are required for meaningful measurements. Quantum Debug builds can be significantly slower than Release builds, so they should not be used to validate final optimization results.

Disable Checksums During Profiling

Set ChecksumInterval in the current session config to 0 while profiling.

Runtime checksums have a performance cost. Disable them during profiling runs so they do not affect the measurement.

After profiling, restore the intended checksum interval if your project uses checksums for validation, debugging, or determinism checks.

Adding the Quantum Graph Profiler

Add the Quantum Graph Profiler prefab to the scene.

Prefab path:

Photon/Quantum/Runtime/GraphProfilers/QuantumGraphProfilerPrefab

The Graph Profiler displays runtime information such as:

frame time;
simulation time;
prediction;
simulated frames;
network activity;
ping;
bandwidth;
entity count;
memory;
custom markers.

In the video example, the scene spawns many physics bodies at startup. This creates a visible workload that makes performance changes easier to observe.

Profiling Physics Sleeping

Quantum Physics Sleeping is enabled by default and is the recommended behavior for most physics-heavy projects.

With Physics Sleeping enabled, inactive physics bodies can stop being processed continuously. In the sample scene, this keeps Update Time smooth and stable even after many physics objects have been spawned.

To demonstrate how the profiler visualizes performance changes, the video disables Physics Sleeping in the Simulation Config.

When sleeping is disabled, all physics objects remain awake. The simulation must continuously calculate physics for them, which increases update time and creates a visible spike in the profiler.

Use this comparison to understand how simulation settings can directly affect runtime cost.

Graph Profiler Entries

The Quantum Graph Profiler contains several groups of metrics.

Engine Delta Time

Engine Delta Time shows the total time the last Unity frame took to run.

Technically, this corresponds to:

Time.unscaledDeltaTime

This value may not reflect your target FPS if vSync is enabled.

Update Time

Update Time shows how the Unity frame was spent.

Entry	Description
`Update`	General engine overhead not covered by the other categories.
`Simulate`	Time spent running the Quantum simulation.
`Render`	Time spent rendering after the last `LateUpdate()` finished.
`Scripts`	Time spent in user scripts during `FixedUpdate()`, `Update()`, and `LateUpdate()`, excluding the Quantum simulation itself.

The Quantum simulation time shown here is based on:

Game.Session.Stats.UpdateTime

Use this graph when you need to determine whether a frame-time issue comes from simulation, rendering, user scripts, or other Unity update work.

Simulation Time

Simulation Time breaks down the Quantum simulation itself.

Entry	Description
`Simulate`	Baseline simulation time not categorized as verified or predicted.
`Verified`	Time spent simulating verified frames.
`Predicted`	Time spent simulating predicted frames.

This is useful when analyzing the runtime cost of prediction and rollback.

Simulated Frames

Simulated Frames shows how many Quantum simulation frames ran during one Unity frame.

Entry	Description
`Verified`	Number of verified frames simulated during the Unity frame.
`Predicted`	Number of predicted frames simulated during the Unity frame.

A high number of simulated frames in a single Unity frame can indicate prediction, catch-up behavior, or simulation pressure.

Prediction

Prediction shows how far ahead the local simulation is predicting.

It is measured in frames and calculated as:

PredictedFrame.Number - VerifiedFrame.Number

This value is relevant for online sessions where prediction is active.

Network Activity

Network Activity shows how long it has been since the client last received data from the server.

This value is only meaningful when connected to Photon Realtime.

Ping

Ping shows the round-trip time between the client and the server in milliseconds.

Lower values indicate lower raw network latency.

Bandwidth

Bandwidth shows current network traffic.

Entry	Description
`In`	Received data in bytes per second.
`Out`	Sent data in bytes per second.

Use this to monitor how much data is being received and sent during online sessions.

Markers

Markers are custom boolean tracking values.

Up to 8 markers can be displayed. Each marker has a unique color.

Default marker examples:

Color	Meaning
Red	Input replaced by server.
Orange	Checksum calculated.

Custom markers are useful for visualizing simulation events, expensive systems, or specific gameplay conditions directly in the profiler graph.

Offline Simulation Notes

Some profiler entries are only populated in online sessions.

If the simulation runs locally and is not connected to Photon Realtime, the following values are not populated:

predicted frames;
network activity;
ping;
bandwidth.

This is expected because these values depend on server communication and online prediction behavior.

Simulating Bad Network Conditions

The bottom panel of the Graph Profiler contains additional runtime data and network simulation controls.

It can show information such as:

entity count;
total memory;
simulated lag;
simulated jitter;
simulated packet loss.

Use the Lag, Jitter, and Loss controls to test how the game behaves under degraded network conditions.

This is similar in purpose to external tools such as Clumsy, but available directly in the Quantum profiling workflow.

Toggling Graph Entries

Most graph entries can be enabled or disabled.

For example, in Update Time, you can toggle off:

Update;
Simulate;
Render.

This allows you to focus only on Scripts.

Filtering graph entries helps isolate a specific performance category when the profiler view contains too much information at once.

Profiling Custom Simulation Work

The example project contains a custom ProfilerSystem.

This system performs intentionally expensive work by searching for the closest target to a transform. The workload is used to create visible profiler spikes and demonstrate how custom simulation cost appears in profiling tools.

The system does not need to run every simulation tick. Instead, it can run at a configurable interval.

At the end of the update loop, the system sends a HeavyTaskPerformed event to Unity. Unity then creates a profiler marker when the heavy work has finished.

This makes the heavy simulation work visible in the profiler output.

Testing Heavy Workload Intervals

The example UI contains a Heavy Load Interval setting.

If the value is set to 1, the heavy workload runs every simulation tick.

If the simulation runs at 60Hz, setting the value to 120 runs the workload every two seconds.

This creates two different profiler patterns:

Interval	Result
`1`	Heavy work runs every simulation tick. Frame rate decreases continuously.
`120`	Heavy work runs every two seconds. Frame rate is mostly stable, with periodic spikes.

A better production approach is usually to distribute expensive work across multiple frames instead of executing all of it in one simulation tick.

This helps keep the simulation more stable and reduces visible frame-time spikes.

Using HostProfiler Markers

The video also shows the use of:

HostProfiler.Start

and:

HostProfiler.End

These markers can be inspected in the Unity Profiler.

Use them to measure how long a specific section of code takes inside the Unity profiling timeline.

If the marked workload only runs at intervals, scrub through the Unity Profiler timeline until the relevant spike is visible.

Finding Quantum Work in the Unity Profiler

Quantum simulation work appears under:

QuantumRunnerBehaviour.Update

Use this area in the Unity Profiler to inspect measurements for Quantum systems and simulation-related work.

This is useful when you want to correlate Unity frame-time spikes with Quantum simulation activity.

Using the Quantum Task Profiler

Quantum also includes its own editor profiler: the Task Profiler.

Open it from:

Tools > Quantum > Window > Task Profiler

The Task Profiler shows how much time Quantum systems and tasks consume.

In the example:

with Heavy Load Interval set to 1, the custom ProfilerSystem consumes a large part of the main thread every tick;
with Heavy Load Interval set to 120, the same system creates a short spike every two seconds.

The Task Profiler also shows built-in Quantum components and systems. These can help explain total simulation cost, although optimizing built-in systems is outside the scope of this video.

Remote Profiling

Remote Profiling can be used to profile the game on an actual device connected to the same network.

This is useful when editor or desktop profiling does not represent the target platform accurately.

Use Remote Profiling when testing on:

mobile devices;
consoles;
standalone VR devices;
lower-end hardware;
any platform where local editor profiling is not representative.

Recommended Profiling Workflow

Use this workflow when investigating performance:

Build with Quantum Release DLLs.
Use an IL2CPP Unity build.
Disable ChecksumInterval.
Run a representative gameplay scenario.
Watch high-level numbers in the Graph Profiler.
Identify whether the issue is simulation, scripts, rendering, or networking.
Use graph toggles to isolate the relevant category.
Use custom markers for known expensive systems.
Inspect marked code in the Unity Profiler.
Inspect Quantum systems in the Task Profiler.
Change one variable at a time.
Re-measure under the same conditions.

Key Concepts

Concept	Description
Quantum Release DLLs	Required for representative performance measurements.
`ChecksumInterval`	Runtime checksum frequency. Should be set to `0` during profiling.
Graph Profiler	Runtime overview profiler for frame, simulation, prediction, network, marker, memory, and entity metrics.
Physics Sleeping	Allows inactive physics bodies to stop being processed continuously.
Update Time	Shows how Unity frame time is split between update, simulation, rendering, and scripts.
Simulation Time	Shows how Quantum simulation time is distributed.
Simulated Frames	Shows how many Quantum frames ran during one Unity frame.
Prediction	Shows how far ahead the local simulation predicts compared to verified frames.
Markers	Custom boolean values used to visualize events or workload in the profiler.
`HostProfiler`	Used to create profiling markers visible in the Unity Profiler.
`QuantumRunnerBehaviour.Update`	Unity Profiler location where Quantum simulation work appears.
Task Profiler	Quantum editor profiler for inspecting system and task costs.
Remote Profiling	Profiling option for testing on actual devices over the same network.

Best Practices

Use this checklist when profiling Quantum performance:

Use Quantum Release DLLs.
Use an IL2CPP Unity build.
Disable ChecksumInterval during profiling.
Restore checksum settings after profiling if needed.
Profile representative gameplay scenarios.
Compare results before and after each optimization.
Use the Graph Profiler for runtime overview metrics.
Use the Unity Profiler for frame-level inspection.
Use HostProfiler markers around specific custom workload.
Use the Quantum Task Profiler to inspect simulation systems.
Test with realistic entity counts.
Test bad network conditions when profiling online gameplay.
Avoid optimizing based on one isolated spike.
Change one variable at a time.
Spread expensive work across multiple frames where possible.
Use Remote Profiling for device-specific performance analysis.

Common Pitfalls

Pitfall	Why It Is a Problem
Profiling with Quantum Debug DLLs	Debug builds can be much slower and may produce misleading results.
Leaving checksums enabled during measurements	Checksum calculation has runtime cost and can distort profiling data.
Profiling only in the Unity Editor	Editor overhead may not represent target runtime performance.
Interpreting local simulation as online behavior	Network, ping, bandwidth, and prediction metrics are not populated locally.
Looking only at FPS	FPS alone does not explain whether the bottleneck is simulation, rendering, scripts, or networking.
Optimizing based on one spike	Isolated spikes may not represent stable runtime behavior.
Running heavy systems every tick unnecessarily	Expensive work may create avoidable frame-time pressure.
Not using markers	Without markers, it is harder to correlate known gameplay events with profiler spikes.
Ignoring target hardware	Desktop profiling may not reflect mobile, console, or standalone device behavior.

Summary

The Quantum Graph Profiler, Unity Profiler, and Quantum Task Profiler provide complementary views of runtime performance.

The Graph Profiler gives a high-level overview of frame time, simulation time, prediction, network activity, bandwidth, memory, entity count, and custom markers.

The Unity Profiler helps inspect frame-level costs and custom HostProfiler markers.

The Quantum Task Profiler shows how much time Quantum systems consume during simulation.

Used together, these tools help identify real bottlenecks, validate optimization results, and avoid misleading conclusions caused by debug builds, checksums, editor overhead, or non-representative profiling conditions.