Superluminal for Unity , Fast Hot‑Path Hunting with Filters & Histograms

Myth: “Sampling profiles are unreadable noise.”

Reality: With Superluminal’s filters and histograms, the noise turns into a roadmap.

In the previous post, we covered Sampling vs Instrumentation in Unity , Field Ops with Very Sleepy , read it here.

You’ve got a captured run, but sifting through call stacks is slow. Superluminal launches, you filter by your script’s class name, and the callgraph jumps straight to MonoBehaviour.Update(), surrounded by the engine work it triggers. The hot‑path view highlights where your time concentrates. Decision made.

TL;DR

• Search your code first: Filter the callgraph by class or method to surface your scripts inside engine stacks.
• Follow the hot path: Use “expand hot path” to auto‑traverse the most expensive route from PlayerLoop to your code.
• Read distribution, not just totals: The histogram shows how cost spreads across calls, revealing spikes vs steady work.
• Decide with context: Compare exclusive vs inclusive time to choose algorithm fixes vs call‑pattern fixes.

Why this matters

Sampling profilers shine when instrumentation can’t see native/engine hotspots your scripts provoke. Superluminal adds the missing usability: filters, hot‑path expansion, and per‑function histograms so you move from “interesting” to “actionable” in minutes.

Business line: Prioritizing the true hot path turns week‑long hunts into sprint‑sized wins.

Opportunity cost

Without smart navigation, you spend your day expanding stacks and second‑guessing. Meanwhile, the real offender, often a call pattern into engine systems, keeps taxing every frame.

Mechanics , why Superluminal works so well here

Usual developer workflow:

• Directly see PlayerLoop → post‑late‑update → render path without manual spelunking.
• Filter by your script/class to jump to IL2CPP’d functions tied to your code.
• Hot‑path expansion auto‑navigates the most expensive chain.
• Pie + histogram views reveal where time concentrates and how it’s distributed.
• Function list search can expose relationships you wouldn’t guess (e.g., transform change dispatch near reflection probe updates).

These are sampling truths, surfaced better:

• “Here we directly see post late update finish frame rendering registrator.”
• “This filter is already invaluable… all the IL2CPP functions that we could find.”
• “expand hot path which is going to navigate automatically for you.”
• “you can see that it’s close by it’s related to the reflection probe manager Update cache reflection probes.”
• “You also get the histogram which is the distribution of cost.”

The Blueprint, hot‑path hunting in Superluminal

Pre‑reqs (from Post 1): build with IL2CPP, rich stack traces, minimal stripping, and archive symbols.

1. Capture a representative run Launch via Superluminal, start capture during real gameplay, then stop once you’ve exercised the problem areas.

2. Jump to your code In the Callgraph, filter by your class or feature keyword (e.g., PlayerCharacterController). Click a method like Update() and Set as Root to simplify the view.

3. Open the door both ways

   • Inclusive time: cost of this function + everything it calls → great for call‑pattern issues (physics queries, rendering calls, transforms).
   • Exclusive time: cost of the function body itself → great for algorithm/GC fixes.

4. Expand the hot path Use Hot Path to automatically traverse the most expensive edges. This often lands you in physics casts, transform dispatch, or rendering submission from your scripts.

5. Check the histogram Is cost spread thin across many calls (broad work), or concentrated in fewer calls (spiky)? Spiky work often maps to hitches you can feel.

6. Corroborate relationships Use the Function List to search engine functions you suspect (e.g., transform change dispatch). When you find them, locate them in the callgraph to see neighboring systems (e.g., reflection probe cache updates).

7. Decide the fix

• If inclusive dominates via engine calls: reduce frequency/patterns (batch, cache, move work out of Update, defer to jobs).
• If exclusive dominates: tune the algorithm, trim allocations, or precompute.

A tiny pattern fix you can apply today

If accessing Camera.main appears in your Unity’s Superluminal path, cache it instead of querying each frame. Although this should be fixed in recent versions of Unity, worth checking. And now you know how.

using UnityEngine;

public class CacheMainCamera : MonoBehaviour
{
    Camera _main;
    void Awake() => _main = Camera.main;

    void Update()
    {
        // Use _main instead of Camera.main each frame.
        // This reduces repeated lookups that can show up in sampling captures.
        if (_main)
        {
            // ... your logic ...
        }
    }
}

Gotchas

• Don’t panic at engine depth. Start from PlayerLoop or your class; let filters/hot‑path guide you.
• Symbols still matter. If names look opaque, verify your symbol setup from Post 1.
• Sampling is approximate. Very short calls may not show, optimize only what you can observe consistently.
• Correlation ≠ causation. If an engine function is hot, confirm your script path that triggers it before changing content pipelines.
• Editor vs Player. Attach to the build for realistic stacks; attach to the Editor only when the workflow itself is the problem.

In the next post, we dig into Player‑Side Smoothness , CapFrameX + PresentMon Percentiles & Overlays , read it here.

Need this done in days, not months? Book a discovery call and hit your frame target frame-rate.

Download the checklist, triage hot paths with a repeatable flow.

https://thegamedev.guru/unity-performance-checklist/

I’ve helped teams turn vague “it feels off” into concrete, repeatable wins, fast. , Ruben (TheGameDev.Guru)