DEV Community: GameOptim

How Do You Tell Whether a Unity Stutter Is From GPU Shader Cost, Bandwidth, or Thread Blocking?

GameOptim — Fri, 06 Nov 2026 02:05:52 +0000

Cycles/Pixel, GPU bandwidth, and a thread timeline read the same frame drop from three angles — so you optimize the right subsystem instead of guessing.

A dropped frame in a modern Unity game rarely has a single cause. Higher-fidelity art pushes Shader cost up, more textures increase GPU memory bandwidth, and heavier logic spreads work across threads. A stutter can come from any of these, and optimizing the wrong one yields no frame-time improvement at all.

GameOptim GOT Online's Overview mode adds two diagnostics that read the same frame from different angles: GPU Counter for shader cost and memory bandwidth, and Timeline for thread-level activity during a stutter. This article explains what each measures, how to read them, and how to decide which one your stutter belongs to.

Summary

A frame drop can come from GPU shader cost, GPU memory bandwidth, or thread blocking — each needs a different fix.
Cycles/Pixel measures the average GPU clock cycles spent per pixel. High values usually mean the Shader is too complex; low values with a stutter point elsewhere.
GPU bandwidth measures per-frame read/write volume. Sustained high external read/write causes fast battery drain and is independent of shader complexity.
Timeline visualizes up to 5 threads with parent and child function durations, so you can see thread count, queueing, idle states, and inter-thread waits during the exact stutter frame.
GPU Counter data is currently available on devices with supported Mali chips; check device compatibility before reading absence as a finding.

What Does "GPU Is Slow" Actually Mean?

"GPU pressure" is three separate things bundled into one complaint. Each has a different symptom and a different fix.

Subsystem	What it measures	Symptom when overloaded
Cycles/Pixel	Average GPU clock cycles per pixel	Shader complexity exceeds per-pixel budget; frame time grows with screen complexity
GPU bandwidth	Per-frame total read/write volume	Sustained high load → fast battery drain, thermal throttling, eventual stutter
Thread timeline	Activity across CPU threads during a frame	Threads idle, queued, or waiting on each other; stutter caused by blocking, not raw compute

These are independent. A game can have low Cycles/Pixel and still drop frames because threads are blocking. A game can have expensive shaders and a clean timeline. The new GOT Online features let you read each separately so you do not optimize one to fix the other.

Cycles/Pixel: Reading Shader Complexity

Cycles/Pixel is the average number of GPU clock cycles consumed per rendered pixel. Shader complexity is the dominant factor: when a scene's shaders are complex, the GPU spends many cycles per pixel evaluating them, GPU time rises, and the frame stutters.

How to read it: Use Cycles/Pixel under GPU shading to identify scenes with high cycle counts, then judge whether the scene's GPU pressure is caused by shader complexity. If the cycles value is high and tracks with shader-heavy scenes, shader simplification is the right lever. If the cycles value is low but the frame still stutters, shader cost is not the cause — look at bandwidth or the thread timeline instead.

What Cycles/Pixel does not tell you: It cannot distinguish between a few very expensive pixels and many moderately expensive ones, and it says nothing about memory traffic. Pair it with bandwidth data before deciding.

GPU Bandwidth: Reading Memory Traffic

GPU bandwidth, like CPU bandwidth, is a major contributor to chip power consumption. When the GPU performs sustained high-load external read/write operations, power draw rises sharply.

The GPU bandwidth module in GOT Online reports the total per-frame read/write bandwidth across the test. Use it to locate scenes where bandwidth is high, identify what is driving the traffic, and run a follow-up test after any changes.

How to read it:

A scene with high bandwidth but normal Cycles/Pixel points at memory traffic — texture streaming, render-target copies, or excessive buffer uploads — rather than shader compute.
A scene with both high bandwidth and high cycles confirms a GPU-heavy scene that needs work on both fronts.
Bandwidth is also a thermal signal: sustained high values lead to throttling and stutter even when raw frame time looks acceptable.

Timeline: Reading Thread Activity During a Stutter

Overview mode already supported stutter analysis through call-stacks. The new Timeline module adds a time-ordered view so the sequence of events is visible at a glance.

Timeline shows the main thread and up to 4 sub-threads (5 total). Under each thread, both parent and child functions are visible, and the length of each function's time bar represents its duration — the longer the bar, the more time that function consumed near that frame.

What the Timeline answers:

How many threads were active during the stutter frame.
What each thread was executing and for how long.
Whether threads were queued behind one another.
Whether any thread was idle or waiting on another thread to finish.

This makes thread-level bottlenecks visible in a way a call-stack cannot. A call-stack tells you what one function did; a Timeline tells you whether another thread was the actual reason the frame did not complete on time.

How Can You Tell Which Subsystem Is Causing the Stutter?

Work through the three signals in this order:

If you see	The cause is likely	What to optimize
Cycles/Pixel high, bandwidth low, timeline clean	Shader complexity	Reduce shader cost, simplify passes, optimize per-pixel work
Bandwidth high, cycles normal, timeline clean	Memory traffic	Reduce texture streaming, render-target copies, buffer uploads
Cycles and bandwidth normal, timeline shows idle/waiting threads	Thread blocking	Re-order work, remove unnecessary waits, balance load across threads
Cycles high and bandwidth high	Combined GPU load	Address both, starting with whichever has the larger headroom gap

A stutter that matches none of these rows may be CPU-side logic or input handling — the new modules do not cover that, and you should check the existing stutter call-stacks instead.

What Should You Check First?

Confirm device compatibility. GPU Counter data requires a supported Mali chip. If Cycles/Pixel and bandwidth are absent, it is a device limitation, not a zero reading.
Start with the stutter frame. Open Timeline and look at the exact frame that dropped. Thread activity at that moment tells you whether the problem is compute, memory, or blocking.
Read Cycles/Pixel next. If the dropped frame also has high cycles, shader cost is involved.
Read bandwidth for the same frame. If bandwidth spiked too, memory traffic is part of the cause.
Correlate across the test. A one-frame spike is different from a scene-wide trend. Check whether the high values persist through the scene or appear only in one frame.

What Should You Avoid?

Do not treat a missing GPU Counter reading as zero. On unsupported devices the data is simply unavailable. Verify chip support first.
Do not optimize shaders when the timeline shows thread waiting. Shader work has no effect on a CPU-side thread-blocking stutter.
Do not reduce bandwidth if the cycles value is the real driver. Cutting texture resolution will not lower Cycles/Pixel if the shader itself is the cost.
Do not read a single frame in isolation. Confirm the signal holds across the scene before making changes.

Key Takeaways

GPU pressure splits into Cycles/Pixel (shader cost), bandwidth (memory traffic), and thread blocking (timeline) — independent signals requiring different fixes.
High Cycles/Pixel means shaders are doing too much per pixel. Low cycles with a stutter means the cause is elsewhere.
High bandwidth drives power draw and thermal throttling, even when frame time looks fine.
Timeline reveals thread count, queueing, idle states, and inter-thread waits — the only way to see a blocking bottleneck.
GPU Counter is available on supported Mali devices; absence is a compatibility note, not a zero.

FAQ

Why is my Cycles/Pixel high but my game looks fine?
Cycles/Pixel measures shader cost per pixel, not visual quality. High values mean the GPU spends many cycles evaluating shaders, which can cause stutter even if the output looks correct. Simplify shaders or reduce overdraw to bring it down.

Does high GPU bandwidth cause stuttering directly?
Not always immediately. Sustained high bandwidth raises power draw and temperature, which leads to thermal throttling and eventual stutter. It also competes with other memory traffic, so spikes can coincide with frame drops.

How many threads does the Timeline show?
Up to 5 — the main thread plus 4 sub-threads. Within each thread, both parent and child functions are shown with duration bars.

What does an idle thread in the Timeline mean?
A thread that is idle or waiting for another thread to finish means the stutter is likely a blocking issue, not a compute shortage. Re-ordering work or removing the wait is more effective than adding more CPU tasks.

My device does not show GPU Counter data. Is that a bug?
GPU Counter currently supports devices with certain Mali chips. If the data is absent, verify that your device uses a supported chip; otherwise the reading is simply unavailable, not zero.

How Do You Find the Lua Function That Is Actually Costing You Frame Time?

GameOptim — Wed, 04 Nov 2026 06:55:51 +0000

A Lua entry in the top-20 cost list is the start of the investigation, not the answer. Three stack views plus a reversed call tree point you at the leaf function worth fixing.

Lua rarely shows up in a Unity performance report as one big number. It shows up as a handful of function names inside the logic-code cost ranking, and the expensive part is usually not the function listed there — it is a leaf several levels down its call stack.

The practical workflow is short: open the GOT Online Lua report's Code Efficiency → CPU Time page, choose the stack view that matches the question you are asking (whole-session, single-scene, or single-frame), then reverse the stack so the deepest and most expensive children surface first. This article walks through that sequence, explains the Lua function naming format the report uses, and covers the one test setting that silently breaks the whole analysis.

Summary

Lua cost appears in reports as individual functions in the top-20 logic cost list, not as a single aggregate figure.
The report offers three stack views: overall cost, specified scene, and any single frame. Each answers a different question; using the wrong one sends you to the wrong function.
Lua functions are identified as X@Y:Z — function name, defining file, defining line. When the name cannot be resolved, X becomes unknown.
When Lua runs as bytecode, the line number Z is always 0. Test with Lua source if you want line-level attribution.
Reverse stack analysis reorders the cost stack so deep sub-functions that actually consume the time appear on top, instead of forcing you to expand dozens of levels by hand.

What Is the Core Problem?

When Lua usage grows in a commercial project, CPU cost spreads across many small functions rather than concentrating in one obviously slow place. In a report, that looks like several Lua functions mixed into the top-20 logic cost list — enough to know Lua is involved, not enough to know where to change code.

The cost hides for two reasons:

The entry function is not the expensive function. A Lua call often passes through wrappers, dispatch tables, and utility layers before reaching the function that does the work. The top-level name accumulates cost; the leaf generates it.
Aggregate and peak are different measurements. A function can dominate total session cost while never appearing in the frame where the game stuttered, and vice versa. Locating one does not locate the other.

Why Does the Cost Hide in the Call Stack?

A stack trace orders calls from the outermost caller to the innermost callee. Read top-down, the first entries are the ones you recognize — event handlers, update loops, framework entry points — and they carry the largest accumulated totals simply because everything below them rolls up into their number.

The actual work sits at the bottom. To see it in the default view, you expand frame after frame, often dozens of levels deep, and the numbers you are comparing are already diluted by sibling branches. That is the structural reason a "Lua is slow" finding stalls: the report is correct, but the ordering hides the answer.

Reversing the stack fixes the ordering. Instead of reading caller → callee, you read callee → caller, so the deepest sub-function with the highest self-cost lands at the top of the view. The bottleneck becomes visible without manual expansion.

How Is a Lua Function Identified in the Report?

Every Lua entry carries a name in a fixed format that maps it back to source:

Part	Meaning	Notes
X	Function name	Falls back to `unknown` when it cannot be resolved
Y	File where the function is defined	The script location, not the call site
Z	Line where the function is defined	Always `0` under bytecode execution

X@Y:Z is enough to search your codebase directly: file plus line lands you on the definition, and the function name confirms it. This is why the format matters more than the visual stack — it converts a profiler row into a code location.

The bytecode caveat is the one that trips teams up. If the Lua scripts are shipped as bytecode, Z is 0 for everything, and you lose line-level attribution entirely. The recommendation is to run the test with Lua source wherever possible, so the stack data stays resolvable.

How Can You Tell Whether the Function Is Actually a Problem?

Match the stack view to the question. Each view isolates a different kind of cost, and the answers do not transfer between them.

View	Question it answers	Use it when
Overall CPU cost stack	Which Lua functions accumulate the most cost across the whole session	Building the hotspot shortlist at the start
Specified-scene stack	Which Lua functions dominate in one particular scene	Cost differs by scene, and you want to target one
Single-frame cost stack	Which Lua functions consumed time in the exact frame where cost peaked	Explaining a specific spike or stutter

Three signals confirm that a function is a genuine target rather than noise:

It appears high in the reversed overall stack, meaning its own cost is large rather than inherited from children.
It reappears in the per-scene view for the scene that carries the memory or frame-time pressure.
It positions itself in the peak frame's stack, so the aggregate number and the visible symptom agree.

If a function only satisfies the first signal, you have found volume, not a bottleneck. If it only satisfies the third, you have found a one-off spike, not a pattern.

What Should You Check First?

Open the Code Efficiency → CPU Time page and confirm Lua entries exist. If Lua does not appear in the top-20 logic cost list, this workflow has nothing to target yet.
Start with the overall stack to build a shortlist. Do not optimize from this list; use it to pick candidates.
Reverse the stack before judging any candidate. The entry with the biggest number in the default order is frequently the caller, not the cause.
Record the X@Y:Z identifier for each candidate. File and line are what make the finding actionable in code review.
Confirm the test ran on source, not bytecode. If every Z is 0, fix the test setup before drawing conclusions — the data is coarse by construction.
Re-check the candidate in the scene view and the peak-frame view. A function that survives all three is a real target.

What Should You Optimize?

Optimize the leaf, then the path that reaches it.

The leaf function itself is where the self-cost sits. The reversed stack identifies it; the X@Y:Z identifier locates it.
The call frequency of that path decides whether the total cost is a problem. The per-frame stack shows what one call costs; the aggregate stack shows how often it happens. A cheap function on a hot path costs more than an expensive function called twice.
The scene where it concentrates tells you whether the fix is local (a scene-specific feature) or systemic (a shared utility used everywhere).

Each change should be re-measured with the same view that produced the finding. A fix that lowers aggregate cost but leaves the peak-frame stack unchanged has moved volume without removing the spike.

What Should You Avoid?

Do not optimize the top entry of the default stack. It inherits cost from everything beneath it; changing it usually means changing design, not code.
Do not profile bytecode builds and expect line numbers. Z = 0 is a test configuration result, not a report bug.
Do not expand the stack by hand to find the bottom. Toggle the reversed view instead; dozens of manual expansions is how bottlenecks get missed.
Do not treat an aggregate hotspot as a frame-time problem without checking the peak frame. Total cost and peak cost point at different code.

Practical Recommendations

Problem	What to inspect	How to judge	What to change	What to re-measure
Lua appears in the cost list but you cannot name the culprit	Reversed overall stack	Highest self-cost at the deepest level	That leaf function	Overall stack
Cost is concentrated in one scene	Specified-scene stack	Same function tops the scene view	Scene-scoped logic	Scene view plus overall
Cost peaks only in one frame	Single-frame stack	Function present in the peak frame	The call path taken in that frame	Peak-frame view
Line numbers are all `0`	Test script delivery	`Z` equals `0` across entries	Run the test on Lua source	Naming resolved to file and line
A candidate looks large but changes nothing when tuned	Peak-frame view	Function absent from the spike frame	Investigate the actual spike frame	Stutter metric, not total cost

Key Takeaways

Lua cost in a report is a list of functions, and the listed function is often the caller rather than the cause.
Reverse stack analysis surfaces the deep sub-function that actually holds the cost.
X@Y:Z — name, file, line — is the bridge from a profiler row to a code location.
Bytecode execution forces Z to 0. Test with source when line-level attribution matters.
Overall, per-scene, and per-frame stacks answer different questions; a real bottleneck shows up in the ones that match your symptom.

FAQ

What does the X@Y:Z format in a Lua stack entry mean?
X is the function name, Y is the file where the function is defined, and Z is the line number of its definition. If the name cannot be resolved, X becomes unknown.

Why is the line number always 0 in my Lua data?
Because the scripts are running as bytecode. Under bytecode execution the line value is always 0, so run the test with Lua source to get usable line-level attribution.

Should I use the overall stack or the single-frame stack?
Use the overall stack to find which functions accumulate cost across the session, and the single-frame stack to explain a specific spike or stutter. A function can be large in total while never appearing in the frame you are investigating.

Why does reversing the stack make the bottleneck easier to find?
The default order lists callers above callees, so entry points carry inflated totals. Reversed, the deepest callee with the highest self-cost appears first, which removes the need to expand dozens of levels manually.

Is a function that tops the overall cost list necessarily the one to optimize?
Not necessarily. It may simply be a caller that aggregates everything beneath it. Confirm that the self-cost is high and that it also appears in the scene or peak-frame view before treating it as a target.

How Can You Tell Whether a Unity Crash Is From GPU Memory, Resource Footprint, or Mono Heap Retention?

GameOptim — Mon, 02 Nov 2026 08:02:58 +0000

One high memory number hides three different root causes. GameOptim GOT Online's new PSS GPU trend, per-resource snapshots, and IL2CPP heap dumps split that single signal into three diagnosable metrics — so you can fix the right subsystem instead of guessing.

Memory pressure crashes are one of the most common reasons a Unity build fails device certification or gets refunded on release. The frustrating part is that "memory is high" is almost never the whole story — GPU memory, general resource footprint, and Mono heap retention all contribute to the final OOM kill, and fixing the wrong one wastes days of iteration.

GameOptim GOT Online's latest release adds three new diagnostics that let you read each subsystem separately, instead of guessing from a single total memory number. This article explains what each new metric actually measures, how to read it correctly, and the caveats you need to know before acting on the data.

Summary

A single high memory value is useless unless you split it into PSS GPU memory, resource memory, and Mono Reserved — each points to a different subsystem with a different root cause.
PSS GPU memory, newly added to GOT Online's Overview mode, shows the rendering memory the graphics driver reports; Android 10 and 11 refresh this value only every 5 minutes, so the curve appears stepped.
The new Memory Usage page combines an overview table (PSS, Mono Reserved, resource, Lua heap) with per-resource breakdowns and frame-level snapshots marked on the time axis.
IL2CPP Mono heap snapshots are now available without a separate Mono build, provided you build with Unity 2019.4+ and Script Debugging enabled.
Sampling strategy matters: manual resource snapshots capture every resource in a frame, while periodic snapshots and Resource-mode data have lower resolution by design to keep instrumentation overhead acceptable.

What Does "High Memory" Actually Mean in Unity?

Unity games draw memory from three distinct pools, and each pool grows for different reasons. Fixing a Mono leak with asset compression, or vice versa, never works.

Subsystem	What it measures	Typical failure mode
PSS GPU Memory	Rendering memory reported by the graphics driver — textures, meshes, driver libraries	OOM kills on Android when GPU memory spikes past the device threshold
Resource Memory	Total memory consumed by textures, meshes, animations, audio, and 7 other categories	Scene transitions that push total resources past device limits
Mono Reserved	Managed heap capacity held by the Mono runtime	Slow growth over a session that eventually exhausts process memory

These three pools are independent. A game with moderate PSS can still crash from GPU memory; a game with stable resource memory can still leak Mono references. The new GOT Online features let you inspect each one without running three separate test passes.

PSS GPU Memory: Reading the Driver's Number

The new PSS GPU memory trend appears in the Overview mode's Runtime Info page. GPU memory is the memory consumed by rendering resources at the driver level — texture data, mesh buffers, and memory allocated by the libraries that parse those resources. Unlike process PSS memory, this value is reported directly by the graphics driver rather than by the OS memory manager.

When GPU memory rises near the device limit, the kernel kills the process — so tracking this number is critical for crash-risk management alongside PSS memory.

Important caveat for Android 10 and Android 11: Due to platform-level restrictions, these OS versions refresh the GPU PSS value only once every 5 minutes after boot. On those devices the curve appears as a step function, and a large jump at frame N actually reflects changes that accumulated over the preceding 5 minutes. When GPU memory spikes appear in reports from Android 10/11, trace back through events in the prior 5-minute window before assigning blame to a single frame.

The Memory Usage Page: One Table, Three Questions

GOT Online's Overview mode now includes a Memory Usage page that consolidates memory diagnostics previously scattered across separate reports. The page is organized into two layers.

Layer 1: The Overview Table

The overview table plots PSS memory, Reserved Mono, and total resource memory on one time axis. When Lua testing is enabled in Overview mode, Lua heap memory is added as a fourth curve. Resource memory here is the sum of all resource memory collected during the test.

GameOptim SDK samples data at five points by default — test start, every 1,000 frames, scene transitions, test end, and manual resource snapshots via the Dump operation. Only manual Dumps capture every resource in the current frame with full detail.

The default view shows three curves — PSS memory, Reserved Mono, and total resource memory — with all resource-object snapshot frames marked on the horizontal axis.

Resource-mode caveat: When Resource mode is enabled alongside Overview mode, the SDK collects detailed per-resource data. To keep instrumentation overhead acceptable, different resource categories are sampled on different frames. The resulting total resource memory is a simulated sum with a 60-frame step — lower accuracy, and hidden by default in the table.

Performance caveat: Running Overview mode with Resource mode enabled introduces measurable overhead (lower frame rate, stutter during collection). Do not use this combination for general gameplay performance analysis — it's specifically for resource memory diagnosis.

Layer 2: Per-Resource Breakdown and Snapshots

The Resource Memory Usage table breaks resource memory into 11 categories: textures, meshes, animations, audio, and seven others. Each category gets its own trend line so you can see exactly which resource type is driving total memory pressure in each scene, and quickly judge which resource type is responsible for memory pressure in each scene.

Selecting a resource snapshot frame (in non-Resource mode) or any frame (in Resource mode) generates two artifacts below the table: a pie-chart preview showing resource-type memory share at that frame, and the corresponding resource detail data.

The resource-object snapshot module does two things at once: it shows the memory-share pie chart of each resource type at the selected frame, and lists every resource type in a table sorted by memory usage (largest first). For each type the table shows the quantity, memory usage, and a recommended-value flag — items exceeding the recommended value are highlighted in red so you can immediately locate categories that need attention.

Clicking the operation column in the table jumps directly to the corresponding tab in the Resource Memory page for deeper analysis. In the Resource Memory page, resource-object snapshot frames are also marked, so selecting any snapshot frame pulls up the detailed resource information for that moment.

The Memory Usage page also supports comparison mode: toggle it on from the bottom right, select any two snapshot frames (non-Resource mode) or any two frames (Resource mode), and the page shows the per-resource memory delta between them — quantity and size for every resource type.

IL2CPP Mono Heap Snapshots: No Separate Mono Build Required

For managed memory analysis, GOT Online adds two new pages under Heap Leak Analysis: Resident Heap Allocation Functions and Heap Object Snapshot. These sit alongside the existing IL2CPP Mono heap allocation data collection, which requires Unity 2019.4 or later with Script Debugging enabled at build time.

Dump rules are configured before the test run — snapshots are collected either at a fixed frame interval or on manual trigger.

Reading the Heap Object Snapshot

Developers can use the bar chart in the Heap Object Snapshot page to quickly identify which scenes retain heap memory worth optimizing. The chart supports two dimensions — heap object size and heap object count — so you can see whether retention comes from a small number of large objects or a large number of small ones.

Heap objects split into two parts: Managed Objects and memory fragmentation. Fragmentation itself splits further into free active memory (used first during allocation) and free fragment memory (used only when active memory is insufficient). Allocation always consumes from free active memory before falling back to fragments.

Below the bar chart, the page shows summary stats for the selected frame: total Managed Object size, total type count, total object count, and fragmentation ratio. On the right, a pie chart shows the share of the top 10 object types by memory usage, with the remainder grouped as "other" — giving you an immediate view of where Mono memory is concentrated so you can lock in on the bottleneck.

Below the pie chart sits the object-type table, which lists every object type in the selected frame along with its size, share, and object count. Expanding any object type reveals every function that allocated that type, and the inverse call path from those functions upward to your code.

This is the critical diagnostic step: the call path tells you exactly where in your code the allocation originates, so you can search for the sub-function and fix the source rather than masking the symptom.

Sampling Caveats That Change How You Read the Data

Three properties of GameOptim's sampling strategy are easy to overlook but directly affect what the data means:

Resource-mode step size. Detailed per-resource data is collected every 60 frames, not every frame. The simulated total curve has deliberate gaps. Do not treat a frame-to-frame dip in the simulated curve as evidence that memory was released.
Dump triggers. Only manual Dump operations capture every resource in the frame. Periodic samples (start, every 1,000 frames, scene transitions, end) are partial snapshots. If you need a complete view of resource state at a specific moment, trigger a manual Dump.
Android 10/11 GPU PSS refresh. As noted above, GPU PSS values on these devices update every 5 minutes. A spike at frame N is not necessarily caused by an event at frame N.

Key Takeaways

PSS GPU memory, resource memory, and Mono Reserved are three independent signals. Each one points to a different subsystem; no single number can diagnose a crash.
Android 10/11 users must account for the 5-minute GPU PSS refresh rate when reading GPU memory spikes.
IL2CPP Mono analysis now works from GOT Online — no separate Mono build needed, provided you build with Script Debugging enabled in Unity 2019.4+.
Manual Dump captures every resource; periodic samples do not. Use manual Dumps when you need a complete frame-level picture.
Resource mode + Overview mode has meaningful performance overhead. Use it for resource diagnosis only, not for general gameplay performance measurement.

FAQ

Why does my Android 11 report show a single frame where GPU memory jumps by 200 MB?
Android 10 and 11 refresh the GPU PSS value only once every 5 minutes. The jump reflects changes accumulated over the preceding 5 minutes, not a single frame's workload.

Do I still need to build a separate Mono build to analyze heap retention?
No. On GOT Online, IL2CPP builds support Mono heap allocation data collection and snapshots, provided you build with Unity 2019.4 or later and have Script Debugging enabled.

The total resource memory in my Resource-mode test looks lower than I expected. Is the report wrong?
When Resource mode is enabled alongside Overview mode, total resource memory is a simulated sum with a 60-frame step and lower accuracy. It is hidden by default for this reason.

How do I compare memory usage between two scenes?
Use the comparison mode in the Resource Memory Usage table. Open comparison mode from the bottom right, select two snapshot frames, and the page shows the per-resource memory delta between them.

Should I always run with Resource mode enabled to get better data?
Resource mode introduces significant overhead (lower frame rate, stutter). Enable it only when you specifically need per-resource breakdowns; for general crash-risk assessment, Overview mode with the new PSS GPU and Mono data is sufficient.

How Large Should a Unity Mono Heap Be Before You Treat It as a Problem?

GameOptim — Fri, 30 Oct 2026 10:49:26 +0000

Heap size on its own is a weak signal. Check Reserved versus Used, whether allocation keeps growing across a session, and whether GC stutter frames line up with your allocation pattern — before you change any code.

A large Mono heap in a Unity game is not automatically a leak, and it is not automatically worth optimizing. The heap number tells you how much memory the managed runtime has reserved. Whether that number is a problem depends on three separate facts:

How much of the heap is actually holding live data (Mono Used) versus merely reserved (Mono Reserved).
Whether the value keeps growing across a session, or settles after the first scene.
Whether managed allocation is producing GC stutter frames during normal gameplay.

GameOptim's guidance treats a Mono heap above roughly 80 MB as a reason to collect Mono data in depth — not as a verdict that the project is leaking. The rest of this article explains how to separate those cases, what to inspect first, and which optimizations are actually worth doing.

Summary

A high Mono heap value is a triage signal, not proof of a leak.
Reserved and Used answer different questions: how much capacity the runtime holds, and how much of it is live. Read them together, never the larger one alone.
Continuous managed allocation causes both memory growth and GC stutter; forced collections such as GC.Collect and UnloadUnused show up as recurring stutter points in profile data.
Lua objects that hold references to Mono objects can keep managed memory alive, so a Lua-side reference graph can look exactly like a Mono leak.
On IL2CPP, Mono heap data can be collected with SDK 2.4.5 or later and Script Debugging enabled, so producing a separate Mono build is no longer a prerequisite for this analysis.

What Is the Core Problem?

Unity's Mono heap is the managed memory area used by C# objects, strings, and the runtime's own bookkeeping. Teams usually arrive at this question after seeing one of two symptoms: the heap value in a report looks large, or the game stutters at intervals that no rendering change seems to fix.

These are different problems wearing the same number:

Concept	What it describes	Why it matters
Mono Reserved	The heap capacity the runtime holds	A high value with low usage means capacity, not retention
Mono Used	Memory currently allocated to live managed objects	Growth here usually means something is still referenced
Allocation churn	How fast new managed memory is being allocated and dropped	Drives GC frequency, and therefore stutter
Leak	Live objects that should have been released but are still referenced	Eventually exhausts memory and can crash the process

A heap can be large and healthy (a big but stable live set), or moderate and unhealthy (a small live set that keeps growing). Optimization decisions made from the Reserved figure alone will frequently target the wrong subsystem.

Why Does a Large Mono Heap Slow Down a Unity Game?

Two mechanisms connect heap size to frame time.

First, allocation triggers collection. Every managed allocation adds to the heap; when the heap crosses a threshold, the runtime runs a garbage collection. That collection consumes CPU time inside a frame, which is why sustained allocation shows up as periodic frame-time spikes rather than a smooth slowdown. Reducing allocation frequency reduces the frequency of those spikes, independent of how large the heap currently is.

Second, reserved memory has a hard ceiling. If a project leaks managed memory badly enough, the heap keeps expanding until the process runs out of memory and the game terminates. On constrained devices this can arrive well before the game looks "heavy" in a desktop profile.

Collecting this data has its own cost, which is why sampling strategy matters. Instrumentation adds work at every probe point, so capturing everything on every frame risks distorting the very frame times you are trying to measure. GameOptim's memory modules therefore sample at key moments — the first frame of a test, every thousand frames, scene-transition frames, and the final frame — instead of recording continuously. Reading a report with that rhythm in mind prevents you from treating a sampling gap as a memory drop.

How Can You Tell Whether the Heap Is Actually a Problem?

Compare the metrics against each other and against time. The combinations below separate a leak from a large-but-stable footprint.

Observation across a session	Likely meaning	Next check
Used rises steadily and never returns	Live objects are being retained	Reference chain — including Lua-held references to Mono objects
Reserved rises while Used stays flat	The heap expanded, but the retained object set did not	Whether the expansion is bounded; it is not, by itself, evidence of a leak
Reserved and Used both high but stable	Large live footprint, stable workload	Whether the device budget tolerates it; optimization is a trade-off decision, not a bug fix
Stutter frames cluster around allocation spikes	GC pressure from allocation churn	Allocation rate per frame, and any forced collection calls
Stutter correlates with scene loads	Load-time allocation, not steady-state	Loading-path functions rather than gameplay allocation

GameOptim's published guidance is to keep the Mono heap within about 80 MB, and to run a Mono-mode session for deeper allocation and leak analysis when the heap runs higher than that. Treat 80 MB as the point at which the question becomes worth a dedicated test, not as a pass/fail line: the acceptable ceiling is set by your target device and the rest of your memory budget.

What Should You Check First?

Work in this order; each step rules out a cheaper explanation before you spend effort on the next.

Confirm the build can report Mono data. On IL2CPP, this requires SDK 2.4.5 or later and the Script Debugging option enabled at build time. Without it, the absence of Mono data is a configuration issue, not a finding. Keep build settings identical between runs you intend to compare.
Collect a session that includes real gameplay. A session that only loads a scene cannot distinguish a live set from a leak. The sampling points — start frame, periodic samples, scene transitions, end frame — are what make growth visible.
Read Reserved and Used as a pair. Establish whether the retainer is capacity or live objects before looking anywhere else.
Check Lua-to-Mono references. If Lua holds references to Mono objects, those objects are never released, and Mono Used climbs with no C# allocation in sight. Lua heap data and Mono object reference data answer this directly.
Check whether the stutter frames are collection frames. GC.Collect and UnloadUnused appear as their own stutter categories, with duration, location, and call frequency. If your spikes belong to those categories, you are looking at collection cost, not at rendering or asset work.
Only then look at loading-path functions. Shader.Parse, Shader.CreateGPUProgram, Instantiate, and LoadingReadObject are the common load-time costs. If stutter happens during scene transitions rather than steady state, this is where the time is going.

What Should You Optimize?

Prioritize by what the data showed, in this order:

Retained objects first. If Used grows and never drops, fix the reference that keeps the object alive — Lua references are the most common blind spot, because the C# side looks clean.
Allocation rate second. If Used is stable but stutter follows allocation spikes, reduce per-frame managed allocation. You are targeting GC frequency, not heap size.
Forced collection calls third. If GC.Collect or UnloadUnused shows up as a stutter category, the call sites are in your own code. The data gives you the timing and frequency to judge whether the call is doing work at a moment the frame cannot afford.
Loading path last, and only if it matched the symptom. Loading stutter is a different problem with different fixes; do not tune steady-state allocation to fix a scene-load spike.

Each of these changes should be followed by a new collection run under the same conditions. Because sampling is periodic, a change that only shifts when allocation happens can look subtle in aggregate numbers while being obvious in the stutter frames.

What Should You Avoid Optimizing Prematurely?

Do not treat the heap number as a diagnosis. A large heap with a stable live set is a capacity decision, not a bug. Cutting it requires giving something up.
Do not read Reserved as if it were Used. The larger of the two figures is often the less actionable one.
Do not produce a separate Mono build by habit. On IL2CPP packages, Mono analysis is available through the SDK and Script Debugging configuration described above.
Do not enable every collection mode at once "to be safe." Each mode adds instrumentation cost, and the combined overhead affects the run to different degrees. Enable Resource or Lua collection inside an Overview session only when you need data from subsystems that must be read together — for example, a texture's size and its Mono-side wrapper in one report — and follow the documented caveats about the performance impact of combined modes.

Practical Recommendations

Step	What to inspect	How to judge	What to change	What to expect
1	Build configuration	Mono data present or absent	Enable Script Debugging, SDK 2.4.5+	Data becomes available without a Mono build
2	Reserved vs Used	Which figure is driving the total	Nothing yet	A clear statement of capacity vs retention
3	Used over time	Monotonic growth across sampling points	Retained reference chain, including Lua	Flattened Used curve after the fix
4	Stutter frame categories	Share of frames attributed to GC	Allocation rate per frame	Fewer collection-triggered spikes
5	Collection call sites	Duration and frequency of `GC.Collect` / `UnloadUnused`	Call timing in your code	Predictable, bounded collection cost
6	Scene-load functions	Load-time stutter categories	Loading path, not gameplay allocation	Load spikes addressed at their actual source

Key Takeaways

A large Mono heap is a measurement question before it is an optimization question.
Mono Reserved shows capacity; Mono Used shows retention. Growth in Used is the leak signal.
GC stutter comes from allocation frequency, not from heap size alone.
Lua references to Mono objects can retain managed memory invisibly to C#-side review.
GameOptim suggests keeping the heap within roughly 80 MB and running a Mono-mode test above that — a trigger for investigation, not a failure threshold.

FAQ

Does a large Mono heap always mean a memory leak?
No. A heap can be large because a large live set is legitimately retained, or because the runtime reserved capacity it has not yet needed. A leak requires Used memory to keep growing across a session without being released.

Is 80 MB a hard limit for a Unity Mono heap?
It is GameOptim's suggested ceiling, and the point at which a deeper Mono-mode test is recommended. The real limit depends on your target device's total memory budget and what else the game needs.

Why can't I see Mono data in my IL2CPP build?
Check the SDK version and the build option: Mono heap collection on IL2CPP requires SDK 2.4.5 or later with Script Debugging enabled. This is a configuration prerequisite, not a runtime behavior to debug.

How can Lua cause a Mono memory leak?
When Lua holds a reference to a Mono object, the managed object stays reachable and cannot be collected. Mono object reference data in the report exposes these links, which is why Lua memory and Mono memory are worth reading together.

Should I enable Mono, Resource, and Lua collection in the same run?
Only when you need those subsystems correlated in one report — for example, resource lifetime next to the managed object that owns it. Each enabled mode adds instrumentation cost, so combined runs should be judged against the documented impact rather than assumed to be free.

How Can You Diagnose Lua Memory Issues in Unity Games?

GameOptim — Mon, 26 Oct 2026 07:56:17 +0000

Summary

Overall Lua heap memory helps track memory usage and the counts of important Lua object types, including tables, userdata, and functions.
Heap allocation call stacks help identify Lua functions responsible for substantial allocations and guide targeted optimization.
Reverse call-stack analysis makes it easier to trace allocations to the Lua function and source location responsible for them.
Cached C# object references can help explain why objects remain referenced and cannot be released as expected.
Lua source files provide more useful function-location information than bytecode for this analysis, because the reported ending line number is always 0 when Lua scripts run as bytecode.

What Are the Main Lua Memory Problems in Unity?

Lua is commonly used to support hot updates, allowing development teams to add features and fix bugs without rebuilding the entire game. However, as Lua usage grows, memory allocation and object lifetime management can introduce runtime performance problems.

Two issues deserve particular attention:

Excessive memory allocation: Lua functions allocate substantial amounts of heap memory, potentially increasing garbage collection (GC) frequency and the cost of GC operations.
Unreleased references: Lua-related references to C# objects remain in a cache, preventing those objects from being released as expected and potentially contributing to C# memory leaks.

These problems require different investigations. Allocation analysis helps identify where memory is being created, while reference analysis helps identify objects that remain referenced over time.

How Can You Analyze Overall Lua Heap Memory?

The overall heap memory report tracks Lua's total memory usage over time, along with the counts of three important Lua object types:

Table
Userdata
Function

By examining these metrics at different frames, developers can determine how Lua memory usage evolves during gameplay.

What Should You Look for in the Memory Trend?

Start by examining Lua's total heap memory across the captured session.

Ask the following questions:

Does Lua memory remain within the expected range during the tested gameplay?
Does memory usage continue to increase as the game runs?
Do changes in total memory coincide with changes in the number of tables, userdata objects, or functions?

The purpose is to establish whether the observed memory usage matches expectations and whether the trend warrants further investigation.

An increasing memory trend is a reason to investigate, not sufficient proof of a memory leak. Use the overall report to identify suspicious periods, then inspect detailed allocations or object references to understand what is happening.

How Can You Find the Lua Functions Allocating the Most Memory?

The overall heap report shows the memory trend, but it does not by itself identify the functions responsible for allocations.

The detailed heap allocation report addresses this problem by allowing developers to inspect allocation call stacks for a specific frame.

This helps answer two practical questions:

Which Lua functions are responsible for substantial heap allocations?
Which lines of Lua code should be investigated for optimization?

Step 1: Select a Frame and Inspect Allocation Call Stacks

Choose a frame of interest and examine the allocation call stacks recorded for that frame.

Focus on functions associated with substantial allocations. Their call stacks provide the context needed to trace allocations through the Lua code.

This approach helps narrow the investigation from a game-wide memory problem to specific functions that may be worth optimizing.

Step 2: Use Reverse Call-Stack Analysis to Locate the Source

The report also supports a reverse call-stack viewing mode, similar to the reverse analysis available for Mono heap memory.

Switching the viewing mode makes it easier to identify the deeper Lua functions responsible for allocations, rather than having to work through the original call-stack order.

The goal is to locate the specific Lua script and source line associated with substantial heap allocation. Developers can then inspect the corresponding code and determine whether the allocation behavior can be improved.

Why Does Lua Function Naming Matter?

Lua functions are represented using the following naming format:

X@Y:Z

Component	Meaning
`X`	Function name. If the name cannot be obtained, it is shown as `unknown`.
`Y`	Location of the file where the function is defined.
`Z`	Ending line number of the function definition.

There is an important limitation: when Lua scripts run as bytecode, the reported ending line number is always 0.

For this reason, developers should use Lua source files during testing whenever possible. Source-based testing provides more useful location information when tracing allocations back to the code that produced them.

How Can Lua References Cause C# Memory Leaks?

Lua memory analysis is not limited to allocations within the Lua heap. References between Lua and C# can also affect object lifetimes in Unity projects.

Lua plugins commonly maintain a cache on the C# side for objects accessed by Lua. This cache helps prevent a C# object from being garbage-collected while Lua still needs to access it.

Without an appropriate reference-management mechanism, a C# object could be collected before Lua attempts to access it again, potentially causing logic errors.

However, a cached reference can also prevent an object from being released when it is no longer needed. If unnecessary references accumulate, they can contribute to memory leaks on the C# side.

This is why investigating Lua-related memory issues sometimes requires examining Mono objects rather than looking only at Lua heap usage.

How Does the Mono Object Reference Report Help?

The Mono object reference report summarizes C# objects held in the relevant caches maintained by Lua plugins.

It provides two useful types of information:

Object types and counts: the types of C# objects present in the cache and the total number of objects for each type.
Destroyed Unity objects: for types inheriting from UnityEngine.Object, the report also counts objects that have already been destroyed.

The second metric is particularly useful when investigating references to Unity objects that have been destroyed but may still appear in the cache.

How Can You Identify Suspicious Object References?

Follow this investigation sequence:

Open the Mono object reference report and review the object types and their counts.
Identify object types whose counts continue to increase across sampling points.
Compare the references at two different sampling points for a suspicious object type.
Use the differences to investigate which Lua references may be unnecessary or improperly retained.

The report helps narrow the investigation to specific object types and changes in their reference counts. Developers can then inspect the relevant Lua code and reference-management logic.

A growing cache count does not automatically establish that every retained object is leaked. The key is to determine whether those references are still required by the game's logic.

What Should You Check First When Investigating Lua Memory Issues?

The most efficient starting point depends on the symptom you observe.

Observed symptom	What to inspect first	Next step
Lua heap memory is unexpectedly high	Overall heap memory trend and Lua object counts	Identify suspicious periods and inspect detailed allocations
Lua heap allocations are substantial	Per-frame allocation call stacks	Use reverse call-stack analysis to locate the relevant Lua functions
C# object counts continue to increase	Mono object reference report	Compare object references at different sampling points
Destroyed Unity objects remain in the cache	Destroyed-object counts for types inheriting from `UnityEngine.Object`	Investigate whether Lua-related references are still being retained
Allocation locations are difficult to identify	Lua function names and source-location information	Prefer source-based Lua testing over bytecode when possible

This sequence separates three distinct questions: how much memory Lua uses, where Lua allocates memory, and which C# objects remain referenced.

Investigating the appropriate report first helps avoid optimizing unrelated code or assuming that every memory increase has the same cause.

Which Lua Memory Analysis Tools Are Supported?

GameOptim GOT Online's Lua memory analysis supports several widely used Lua plugins:

uLua
ToLua
SLua
xLua

If a development team recompiles the Lua native library under a custom name, the library name can be specified through the UWAEngine.SetOverrideLuaLib interface.

This configuration is relevant when the project's Lua native library does not use one of the expected library names. Correctly identifying the library helps the analysis support the project's Lua integration.

Key Takeaways

Track trends before diagnosing leaks. Overall Lua heap memory and object counts help identify suspicious changes during gameplay.
Trace allocations to their source. Per-frame allocation call stacks and reverse stack viewing help locate Lua functions and source lines responsible for substantial allocations.
Use Lua source files during testing when possible. Bytecode execution causes the reported function-ending line number to remain 0.
Investigate references as well as allocations. Lua plugin caches can retain C# objects and contribute to memory leaks if references are no longer needed.
Compare multiple sampling points. Changes in cached object counts and references help narrow down suspicious object lifetimes.

FAQ

1. Does increasing Lua heap memory always indicate a memory leak?

No. An increase in Lua heap memory is a signal to investigate, but it does not prove that a memory leak exists. Check the memory trend, object counts, and detailed allocation data before drawing a conclusion.

2. How can I find the Lua function responsible for excessive allocations?

Use the detailed heap allocation report to inspect allocation call stacks for a specific frame. Reverse call-stack viewing can help trace substantial allocations to the relevant Lua function and source location.

3. Why does the Lua function's ending line number show `0`?

When Lua scripts run as bytecode, the reported ending line number is always 0. For more useful source-location information during allocation analysis, use Lua source files in testing whenever possible.

4. Why can Lua cause memory leaks in C# objects?

Lua plugins commonly maintain C#-side caches to keep objects referenced by Lua from being collected prematurely. If objects remain in these caches after the references are no longer needed, they may not be released as expected, contributing to C# memory leaks.

5. How can I investigate destroyed Unity objects that remain referenced?

Use the Mono object reference report to inspect destroyed-object counts for cached types that inherit from UnityEngine.Object. Compare references across sampling points and investigate whether Lua-related references are being retained unnecessarily.

How Can Unity Developers Identify Asset Loading Bottlenecks with GOT Online?

GameOptim — Tue, 20 Oct 2026 08:42:15 +0000

Summary

Asset loading delays and excessive resource operations can cause noticeable stuttering in Unity games. To help developers identify the underlying causes, GameOptim's GOT Online Overview mode introduces Resource Management, which provides quantitative analysis of resource loading and unloading, as well as GameObject instantiation and activation. Developers can inspect execution time, call frequency, AssetBundle information, and the APIs used for resource operations.

GOT Online also adds scene segmentation, allowing developers to analyze performance costs within specific scenes, UI screens, or other sections of gameplay. These features help development teams narrow down loading bottlenecks and conduct more targeted performance investigations.

Introduction

As a Unity project grows in complexity and the number of assets increases, resource loading can become a significant performance concern. However, identifying which resource, AssetBundle, or loading operation is responsible for excessive execution time is not always straightforward.

GameOptim has enhanced GOT Online's Overview mode with resource management analysis and scene segmentation. These features allow developers to examine resource operations quantitatively and break down performance data into more specific sections, making it easier to investigate loading bottlenecks and understand where execution time is being spent.

Main Body

How Can You Identify Asset Loading Bottlenecks in Unity?

Resource loading is an important area to investigate when diagnosing performance issues. As a project becomes more complex and contains more assets, loading operations can become more noticeable sources of stuttering.

The key question is: Which resources, AssetBundles, or loading operations are consuming the most time?

Previously, GameOptim shared techniques for investigating this problem in a technical article about resource loading. With the new Resource Management feature in GOT Online's Overview mode, developers can now quantify the execution costs of individual resource operations directly in the online report.

The analysis covers operations such as:

Resource loading and unloading.
GameObject instantiation and activation.
Execution time and operation frequency.

This detailed breakdown helps developers identify the specific operations that deserve further investigation instead of relying solely on overall loading performance.

Which Resources Should You Investigate First?

The Resource Management overview highlights the top 10 resources with the highest loading costs and the top 10 with the highest operation frequencies that warrant attention.

By surfacing these high-priority resources, GOT Online helps developers focus their investigation on operations with significant execution costs or frequent calls.

Reviewing these resources first can help teams prioritize their optimization efforts and identify opportunities for improvements without having to inspect every resource individually.

How Can You Analyze AssetBundle Loading and Resource APIs?

In addition to the overall resource statistics, GOT Online provides a dedicated Resource Loading/Unloading page for examining individual loading operations.

For each relevant operation, developers can inspect:

AssetBundle: Which AssetBundle contains the loaded resource.
API used: Which interface was used to load the resource.
Execution time: How long the loading operation took.
Call count: How many times the operation occurred.

This information helps developers investigate both the resources involved and the methods used to load them. For example, when a resource appears among the high-cost or high-frequency operations, developers can examine its AssetBundle, loading API, execution time, and call count to better understand the source of the cost.

How Can Scene Segmentation Improve Performance Analysis?

Performance data aggregated across an entire gameplay session may not provide enough detail to determine which scene or UI section is responsible for a particular cost.

GOT Online introduces scene segmentation, allowing developers to divide captured performance data into more specific sections. This makes it possible to analyze execution costs for different scenes, UI screens, and other parts of a gameplay flow separately.

To configure scene segmentation, open Scene Overview → Scene Management and click Add Scene Marker. Enter the segmentation position and scene name to define the new section. GOT Online can then present the corresponding performance analysis based on the updated segmentation.

What Does Performance Analysis Look Like Before Scene Segmentation?

Before segmentation, performance data is presented without the newly defined section boundaries, making it harder to isolate costs associated with a particular part of the gameplay flow.

How Does Scene Segmentation Change the Analysis?

After segmentation, developers can examine the data within the newly defined sections, making it easier to distinguish performance costs associated with different scenes or UI sections.

By dividing performance data into meaningful sections, teams can conduct more focused investigations and better understand how execution costs vary across different parts of the game.

What Is GOT Online, and Which Performance Analysis Modes Does It Support?

GameOptim GOT Online is a lightweight performance analysis service built on its local testing workflow. Development teams can quickly synchronize locally collected performance data to the GameOptim website and generate online analysis reports.

GOT Online combines local testing with online report access, allowing teams to review performance data through a centralized reporting workflow.

The service currently provides four performance analysis modes:

Overview: Overall performance analysis.
Mono: Mono heap memory analysis.
Lua: Lua performance analysis.
GPU: GPU performance analysis.

These modes support different aspects of game performance investigation, from overall execution costs and resource loading to memory usage, Lua behavior, and GPU performance.

What Should Unity Developers Take Away?

Prioritize high-cost resource operations: Use Resource Management in Overview mode to identify resources with high loading costs or operation frequencies.
Inspect individual loading operations: Check AssetBundle information, the APIs used, execution time, and call count to investigate loading bottlenecks.
Analyze GameObject operations: Examine the time spent instantiating and activating GameObjects alongside resource loading and unloading.
Use scene segmentation for finer analysis: Divide performance data into specific scenes or UI sections to isolate execution costs.
Choose the appropriate analysis mode: Use Overview for overall performance, Mono for heap memory, Lua for Lua performance, and GPU for GPU performance.

FAQ

Q1. How can Unity developers identify which assets cause loading bottlenecks?

Use Resource Management in GOT Online's Overview mode to examine resource loading costs and operation frequencies. The overview highlights the top 10 resources in each category, helping developers prioritize their investigation.

Q2. What information does GOT Online provide for resource loading operations?

The Resource Loading/Unloading page shows which AssetBundle contains a resource, which API was used, how much time the operation took, and how many times it occurred.

Q3. Can GOT Online analyze GameObject instantiation and activation costs?

Yes. Resource Management provides quantitative analysis of GameObject instantiation and activation, alongside resource loading and unloading operations.

Q4. What is scene segmentation in GOT Online?

Scene segmentation allows developers to divide performance data into specific sections, such as individual scenes or UI screens, so they can analyze execution costs more precisely.

Q5. How do you configure scene segmentation in GOT Online?

Navigate to Scene Overview → Scene Management, click Add Scene Marker, and enter the segmentation position and scene name. The report can then display performance data according to the defined sections.

Q6. Which performance analysis modes does GOT Online support?

GOT Online provides four modes: Overview for overall performance analysis, Mono for Mono heap memory analysis, Lua for Lua performance analysis, and GPU for GPU performance analysis.

How Can Unity Developers Identify GC Stutters, Lua Leaks, and Mono Memory Issues with GOT Online?

GameOptim — Fri, 16 Oct 2026 06:26:13 +0000

Summary

Investigating game performance issues often requires developers to connect CPU execution costs, garbage collection (GC) activity, Lua function calls, and Mono heap memory usage. GameOptim's GOT Online provides analysis capabilities across Overview, Lua, and Mono modes to help development teams identify performance bottlenecks and investigate memory-related problems.

This article introduces several improvements to these modes, including GC call-frequency monitoring, CPU call-stack visualization, reverse Lua call-stack analysis, Lua leak investigation caused by Mono references, and more detailed Mono heap allocation and object-reference analysis. These features help developers move from observing performance symptoms to examining the functions, objects, and memory changes behind them.

How Can You Detect Frequent GC Calls in Unity?

Garbage collection (GC) activity is one of the important indicators to examine when investigating game stuttering. To help developers monitor GC call frequency, GOT Online has added GC statistics to the loading module in Overview mode.

GC call frequency is influenced by heap memory allocation. When functions allocate more heap memory, or allocate it more frequently, GC can be triggered sooner.

If GC.Collect is called frequently, as illustrated in the image above, developers should investigate the allocation behavior of the functions involved. This is particularly important when GC calls become increasingly frequent as the game runs longer.

In such cases, developers can use GameOptim GOT Online's Mono mode to investigate whether Mono memory is being allocated too quickly or in excessive quantities. This helps connect observed GC activity with potential heap allocation issues that warrant further analysis.

How Can You Identify CPU Performance Hotspots More Quickly?

GOT Online has improved the CPU call-stack analysis page to make it easier to understand execution-time trends and identify functions that contribute to CPU workload.

The CPU execution-time chart displays the overall execution-time trend alongside the trends for top functions. By comparing these curves, developers can quickly identify which functions may be contributing to execution-time peaks.

This visualization makes it easier to examine changes in CPU execution time and investigate which functions are associated with unusually high values.

The updated page also supports scene-specific analysis. Developers can navigate to a particular scene and examine the execution-time distribution of individual functions within that scene.

This makes it easier to narrow the investigation to the relevant scene instead of relying only on aggregated CPU performance data.

How Can Reverse Call-Stack Analysis Help Identify Lua Performance Issues?

Reverse analysis is one of the useful features in GOT Online's Lua mode because it helps developers trace memory allocation back through function relationships without repeatedly expanding deep call stacks.

In reverse-analysis mode, expanding a node displays a list of direct parent functions that call the function represented by that node and generate heap allocations. By following these relationships, developers can trace the allocation back toward the functions responsible for it.

This approach reduces the need to navigate deeply nested call stacks one level at a time and helps developers narrow down the underlying allocation source more directly.

The latest version also adds self-time percentage to the stack information for a selected frame. This metric helps developers identify functions that account for a larger proportion of the execution time within the analyzed stack.

By examining self-time percentage alongside the existing stack information, developers can more easily identify functions that deserve closer investigation when analyzing performance costs.

How Can You Investigate Lua Memory Leaks Caused by Mono References?

Lua memory leaks caused by Mono references are another important area of investigation in GOT Online's Lua mode.

In the latest version, GOT Online improves how Mono objects are presented during leak analysis. Developers can inspect detailed information about Mono objects on a single page, including the number of destroyed objects and how that number changes over time.

The comparison mode also allows developers to compare different sampling points and examine whether the observed memory changes are reasonable.

By reviewing object details, destruction counts, and changes between samples, developers can investigate potential Lua leaks associated with Mono references and determine which changes require further analysis.

How Can You Understand Where Mono Heap Memory Is Being Used?

High Mono memory usage can be difficult to investigate because memory problems can arise in different ways. Developers need to understand not only how much memory is occupied, but also where that memory is being used.

GOT Online's latest Mono mode improves the presentation of heap memory leak analysis, making it easier to investigate why Mono memory usage is high and how the memory is distributed.

The visualization provides an overview of Mono memory usage, helping developers examine the memory distribution and identify areas that warrant closer investigation.

How Can You Trace Mono Heap Memory Back to Specific Functions and Variables?

GOT Online provides additional details at both the function and memory-sample levels to help developers investigate Mono memory usage.

The function view displays the actual heap memory usage associated with each function during game execution. This helps developers examine which functions are associated with memory consumption.

Developers can also select any bar in the chart below to inspect details about actual heap memory usage and the variables residing in memory at that sample.

Within the Mono object reference view, developers can select any two memory samples from the bar chart and compare their memory changes. This comparison helps them identify specific functions associated with memory growth and investigate the corresponding memory increments and variables.

By tracing changes across sampling points, developers can narrow down potential sources of memory leaks and gather more specific information for further debugging and remediation.

What Should Unity Developers Take Away?

Monitor GC call frequency: Use GC statistics in Overview mode to investigate frequent GC.Collect calls and potential excessive heap allocation.
Use CPU execution-time trends: Compare overall CPU costs with top-function trends and inspect specific scenes to narrow down performance hotspots.
Trace Lua allocations through reverse analysis: Follow parent-function relationships to investigate allocation sources, and use self-time percentage to identify functions with higher execution costs.
Compare Mono object samples: Examine object details, destruction counts, and changes between sampling points when investigating Lua leaks caused by Mono references.
Trace Mono memory to functions and variables: Use function-level heap memory data and comparisons between memory samples to investigate memory growth and potential leak sources.

FAQ

Q1. How can developers investigate frequent GC calls in Unity?

Developers can use the GC statistics in GOT Online's Overview mode to examine GC call frequency. If calls become increasingly frequent during gameplay, they can use Mono mode to investigate whether heap memory allocation is occurring too quickly or in excessive quantities.

Q2. How does GOT Online help identify CPU performance hotspots?

Overview mode displays overall CPU execution-time trends alongside trends for top functions. Developers can examine execution-time peaks, investigate the functions associated with those peaks, and use scene-specific analysis to inspect function execution-time distributions within individual scenes.

Q3. What is reverse analysis in GOT Online's Lua mode?

Reverse analysis displays direct parent functions that call a selected function and generate heap allocations. Developers can follow these function relationships to trace allocations toward their sources without repeatedly navigating deeply nested call stacks.

Q4. How can developers investigate Lua leaks caused by Mono references?

Developers can inspect Mono object details, including destruction counts and their trends, in GOT Online's Lua leak analysis. They can also compare sampling points to investigate memory changes and determine whether the observed increments warrant further investigation.

Q5. How can GOT Online help investigate Mono memory leaks?

Mono mode provides function-level heap memory usage, detailed information about memory usage at selected samples, and the variables residing in memory. Comparing two sampling points in the Mono object reference view helps developers investigate memory increments and identify functions and variables associated with potential leaks.

How Can Unity Developers Identify and Analyze Stuttering Frames with GOT Online?

GameOptim — Tue, 13 Oct 2026 09:19:34 +0000

Summary

Identifying the root cause of frame stuttering in Unity games can be time-consuming, especially when developers need to inspect performance data and function call stacks manually. GOT Online's Overview mode now includes a Stutter Analysis feature that automatically identifies stuttering frames and provides detailed function stack statistics for each identified point.

This article explains how stuttering frames are identified in GOT Online, what function stack data is available, and how Unity developers can use this information to investigate performance issues more efficiently.

Introduction

Frame stuttering can negatively affect the gameplay experience, but identifying its root cause requires more than simply observing a drop in frame rate. Developers need to determine which frames experienced significant delays and investigate the function calls responsible for the additional execution time.

To make this process more efficient, GameOptim has introduced Stutter Analysis in GOT Online's Overview mode, incorporating feedback from development teams. The feature identifies stuttering frames during gameplay and provides detailed function stack statistics to help developers investigate the underlying causes.

What Qualifies as a Stuttering Frame in GOT Online?

GOT Online's Stutter Analysis feature identifies frames that meet both of the following conditions:

The current frame time exceeds 83.33 ms.
The current frame time exceeds twice the average frame time of the previous three frames.

A frame must satisfy both conditions to be classified as a stuttering frame.

By applying these criteria, GOT Online lists the identified stuttering frames in a dedicated Stutter Analysis section on the Overview report page. Developers can use this list to quickly locate frames that experienced significant delays during execution.

Image: Stutter Analysis section in the GOT Online Overview report

What Function Stack Data Is Available for Each Stuttering Point?

Identifying a stuttering frame is only the first step. Developers also need to investigate which function calls contributed to the delay.

GOT Online provides detailed function stack statistics for the relevant nodes associated with each stuttering point. The available information includes:

Execution time percentage: The proportion of time attributed to a function or node.
Execution time: The specific time consumed.
Call count: The number of times the function was called.

These metrics help developers examine the execution costs associated with abnormal nodes and investigate the function stacks behind a stuttering frame.

Image: Function stack statistics for a stuttering point in GOT Online

How Can Developers Use Stutter Analysis to Investigate Performance Issues?

GOT Online allows developers to switch quickly between different stuttering points and inspect the corresponding function stacks.

This workflow helps development teams move from identifying a frame-time anomaly to examining the detailed execution data associated with that specific point.

Rather than investigating every frame manually, developers can focus on the identified stuttering frames, compare the relevant function stack information, and use execution time, time percentage, and call count to investigate potential causes.

The function stack data provides a more detailed basis for determining which parts of execution warrant further investigation, helping developers locate the specific causes of stuttering more efficiently.

How Does Stutter Analysis Fit into the GOT Online Overview Workflow?

Stutter Analysis is integrated directly into the Overview report in GOT Online. Developers can review the list of stuttering frames and inspect the corresponding function stack statistics within the same reporting workflow.

This integration connects two important stages of performance investigation:

Identify abnormal frames: Locate frames that meet the stuttering criteria.
Inspect execution details: Examine function stack statistics at each stuttering point to investigate the cause.

By bringing these capabilities together, GOT Online helps streamline the process of moving from frame-time anomalies to detailed performance analysis.

What Should Unity Developers Take Away?

Check both stuttering criteria: A frame must exceed 83.33 ms and twice the average frame time of the previous three frames.
Start with the identified frames: Use the Stutter Analysis section in the GOT Online Overview report to locate stuttering points.
Inspect function stack statistics: Examine execution time percentage, execution time, and call count for relevant nodes.
Compare different stuttering points: Switch between identified frames to investigate their corresponding function stacks.
Use detailed execution data to guide investigation: Move beyond identifying frame-time anomalies and investigate the specific causes through function stack analysis.

FAQ

Q1. What is considered a stuttering frame in GOT Online?

A frame is classified as a stuttering frame when its frame time exceeds 83.33 ms and is more than twice the average frame time of the previous three frames. Both conditions must be met.

Q2. Where can I find stuttering frames in GOT Online?

Stuttering frames are listed in the Stutter Analysis section of the Overview report in the latest version that includes this feature.

Q3. What information does GOT Online provide for each stuttering point?

GOT Online provides detailed function stack statistics, including execution time percentage, specific execution time, and call count, helping developers investigate the execution costs associated with abnormal nodes.

Q4. How can developers investigate the causes of stuttering?

Developers can switch between different stuttering points and inspect their corresponding function stacks. By examining execution time, time percentage, and call count, they can investigate which function calls may be contributing to the observed delays.

Q5. Is Stutter Analysis available in GOT Online's Overview mode?

Yes. GameOptim has introduced Stutter Analysis in GOT Online's Overview mode, adding a dedicated section for identified stuttering frames and their associated function stack statistics.

How Can Unity Developers Track Managed Heap Allocations on Worker Threads?

GameOptim — Fri, 09 Oct 2026 03:21:28 +0000

Moving work that does not require Unity APIs to worker threads can reduce main-thread pressure and help improve frame rates. However, identifying managed heap allocations on these threads can be challenging because Unity Profiler may not show their GC.Alloc activity.

GOT Online's Mono mode now supports multithreaded allocation statistics, allowing developers to inspect managed heap allocations made by non-main threads, investigate potential memory leaks, and compare heap growth between snapshots.

New users can get 2 hours of free GOT Online testing time after completing registration.

Introduction

To reduce main-thread workload and improve frame rates, Unity developers often move operations that do not depend on Unity APIs to worker threads.

However, when analyzing managed heap usage, it can be difficult to identify exactly where allocations occur on these threads. This makes memory profiling and leak investigation more challenging.

To address this issue, GOT Online supports multithreaded statistics in Mono mode. Combined with GOT Online's flexible workflow for testing changes and checking results, this feature helps developers investigate memory allocation issues more efficiently.

Why Should Unity Developers Track Heap Allocations on Worker Threads?

Consider a component that starts two worker threads in Start(). Both threads periodically allocate managed heap memory.

In this scenario, Unity Profiler may not display the GC.Alloc activity associated with these worker-thread allocations.

However, these allocations still matter. Like allocations on the main thread, they can contribute to garbage collection overhead when allocations occur frequently. If objects remain referenced longer than intended, they can also contribute to sustained heap growth or memory leaks.

Being able to identify where these allocations originate is therefore important when investigating managed memory usage in multithreaded Unity projects.

How Can GOT Online Identify Managed Allocations on Worker Threads?

Run a test using Mono mode in GOT Online, then open the Detailed Heap Allocations page in the performance report.

Functions associated with allocations on non-main threads appear with the Thread prefix. This indicates that the function was called on a non-main thread and performed managed heap allocations.

Select a function to inspect its allocation details.

This allows developers to investigate allocation activity that may otherwise be difficult to identify when focusing only on the main thread.

How Can Developers Investigate Heap Growth and Potential Memory Leaks?

Allocations on worker threads can also be relevant when investigating managed heap growth.

If objects remain referenced and cannot be reclaimed by the garbage collector, the corresponding memory growth can be examined in the Heap Memory Leak Analysis panel.

Developers can locate the relevant function and compare two selected nodes to inspect changes in heap usage between them.

This comparison helps developers investigate whether heap usage is increasing over time and narrow down the functions associated with that growth.

How Can Developers Inspect the Objects Behind Heap Allocations?

After identifying a function of interest, click the blue button on the right to view the associated managed heap object types.

The report displays the allocation size and object count for each type, helping developers understand which objects account for the observed memory usage.

This additional detail can help developers determine whether a function is allocating too frequently or contributing significantly to heap growth.

What Should Unity Developers Take Away?

Moving work to worker threads can reduce main-thread pressure, but managed heap allocations on those threads still need to be monitored.
Unity Profiler may not expose all worker-thread allocation activity through the expected GC.Alloc view.
GOT Online Mono mode identifies non-main-thread allocation functions with the Thread prefix.
The Detailed Heap Allocations page provides function-level allocation details.
Heap Memory Leak Analysis helps developers investigate memory growth and compare selected nodes.
Object type, allocation size, and object count provide additional clues for diagnosing memory issues.

By including worker-thread allocations in managed memory analysis, Unity teams can investigate heap usage more comprehensively instead of focusing exclusively on the main thread.

FAQ

Can worker threads allocate managed heap memory in Unity?

Yes. Worker-thread code can allocate managed objects, depending on the operations it performs. These allocations can contribute to garbage collection overhead and sustained heap growth.

Why might Unity Profiler not show worker-thread allocations in the expected `GC.Alloc` view?

The allocation activity described here may not be visible in the usual Unity Profiler view. GOT Online Mono mode provides additional statistics for investigating managed heap allocations made by non-main threads.

How does GOT Online identify worker-thread allocation functions?

In the Detailed Heap Allocations page, functions associated with allocations on non-main threads are marked with the Thread prefix.

Can GOT Online help investigate memory leaks involving worker threads?

Yes. Developers can use Heap Memory Leak Analysis to examine heap growth associated with relevant functions and compare two selected nodes. Object types, allocation sizes, and object counts provide further information for investigation.

About GameOptim GOT Online

GameOptim GOT Online is a cloud-based performance analysis platform for Unity game development. It provides tools for investigating CPU, GPU, and memory performance, helping development teams identify bottlenecks and analyze issues using detailed test reports.

Its Mono mode supports managed heap allocation analysis, including multithreaded allocation statistics, to help developers investigate memory behavior beyond the main thread.

How Can Unity Teams Analyze Performance Across Multiple Test Devices at Once?

GameOptim — Tue, 29 Sep 2026 07:56:47 +0000

How Can Unity Teams Analyze Performance Across Multiple Test Devices at Once?

Summary

As game teams increasingly run automated performance tests across multiple physical devices at the same time, the amount of test data can quickly grow from a few reports to dozens or even hundreds.

Reviewing these reports one by one is time-consuming and makes it difficult to quickly determine which devices, test cases, or performance metrics require attention.

GOT Online now provides Batch Test Analysis, which automatically analyzes multiple test reports and generates an Excel file containing an overall test summary, optimization tasks, affected device models, test failures, and performance data.

This allows development teams to move from reviewing individual reports to identifying common performance problems across an entire batch of automated tests.

Introduction

A typical automated performance testing workflow may look like this:

Build the game → Install it on multiple physical devices → Run automated tests → Collect performance data → Upload the data to GameOptim → Analyze the results

Running tests in parallel across many devices can significantly reduce testing time and increase scenario coverage.

However, this approach creates a new problem: how do you efficiently analyze dozens or hundreds of test results?

There are usually two questions that development teams need to answer:

Which devices and test cases have performance problems?
Did any functional problems occur during testing, such as crashes or blocked gameplay?

To address these problems, GOT Online introduces Batch Test Analysis.

How Can Developers Analyze Multiple GOT Online Reports at Once?

In an Overview mode report, developers can select Batch Test Analysis, choose the test data to analyze, and click Start Analysis.

The system then automatically generates an Excel workbook containing five sheets:

Test Overview
Optimization Queue Details
Devices with Significant Performance Issues
Test Failure Details
Performance Reports

Each sheet provides a different perspective on the batch test results.

What Can the Test Overview Tell You?

The Test Overview sheet provides a high-level summary of the overall test results.

For example, in the following test, the compatibility pass rate is 40%. Among the 10 analyzed tests:

4 passed the performance criteria
5 failed the performance criteria
1 exited unexpectedly due to a crash

Instead of opening each report individually, developers can use these summary results to quickly understand how the project performs across the tested devices.

This is especially useful when a test batch contains a large number of devices.

How Can Batch Analysis Identify Common Performance Problems?

The Optimization Queue Details sheet summarizes performance problems that appear across the analyzed test data.

Rather than simply reporting that a test failed, the analysis provides more detail about the performance bottlenecks, including the affected modules and devices.

This gives the development team a clearer picture of which performance problems occur repeatedly across the test batch.

It also makes optimization prioritization more meaningful.

For example, a performance issue that appears across many devices may deserve higher priority than an issue that occurs in only one specific test case.

Can Batch Analysis Identify the Specific Devices Affected by a Bottleneck?

Yes.

The analysis can drill down to the specific device, test case, and performance module associated with a performance problem.

The report also provides links to the corresponding performance reports.

Developers can therefore use the batch analysis to first identify the problematic devices and test cases, then open the individual reports for deeper investigation.

This creates a two-step workflow:

Batch analysis → Identify the problem → Open the detailed performance report

How Can Developers Find Crashes During Automated Testing?

Performance is not the only issue that can occur during automated testing.

A test may also encounter functional problems such as:

Game crashes
Unexpected exits
Gameplay tasks that cannot be completed
Other test failures

If a crash occurs during one of the test cases, the Test Failure Details sheet records relevant information about that test.

Developers can use information such as:

Device
Test time
Runtime duration before the crash
Memory usage at the time of the crash

as clues for further investigation.

This means that automated testing can provide more than performance data. It can also help teams identify functional failures encountered during the testing process.

What Performance Data Can Be Compared Across Test Cases?

The Performance Reports sheet provides an overview of important high-level performance metrics.

These include:

FPS
Memory
Power consumption
Temperature
Network traffic

The report also provides scenario-level performance information, allowing developers to identify which gameplay scenarios may contain performance bottlenecks.

This makes it easier to connect a performance problem with the specific scenario in which it occurs.

When Is Batch Test Analysis Useful?

Batch Test Analysis is particularly useful for workflows that combine GOT Online with automated testing across multiple physical devices.

Compared with simply checking device compatibility, this approach provides more targeted performance information.

Instead of asking only:

"Does the game run on this device?"

developers can ask:

"Which performance problems occur on which devices, how frequently do they occur, and which problems should we optimize first?"

At the same time, crash information collected during the test provides another layer of information that development teams often need when running automated tests.

What Are the Requirements for Batch Test Analysis?

Batch Test Analysis is available for GOT Online test data generated on or after August 14.

The following conditions must be met:

Each individual test must run for at least 3 minutes.
At least 5 test data records are required.

When these conditions are satisfied, the Batch Test Analysis feature can be used to analyze the test batch.

What Should Teams Consider When Using Poco Automation?

When using the Poco-based automated testing scripts with GOT Online's Overview mode, the scripts may introduce additional CPU overhead.

Development teams should therefore also consider optimizing the Poco automation scripts themselves.

Otherwise, some of the CPU workload observed during the test may come from the automation process rather than the game itself.

This is particularly important when evaluating CPU-related performance metrics.

What Should Unity Teams Take Away?

Running performance tests across many physical devices provides broader coverage but also creates a large amount of data to analyze.
Batch analysis can identify common performance problems without requiring developers to manually inspect every report.
Performance issues can be traced to specific devices, test cases, and performance modules.
Crash information can be analyzed alongside performance test results.
FPS, memory, power, temperature, and network data provide a high-level view of performance across the test batch.
Individual performance reports can then be opened for deeper investigation.
When using Poco-based automation, teams should account for the CPU overhead introduced by the automation scripts.

FAQ

Q1. What is Batch Test Analysis in GOT Online?

Batch Test Analysis allows developers to analyze multiple GOT Online test reports together instead of reviewing them individually. It generates an Excel workbook containing test summaries, optimization information, affected devices, test failures, and performance data.

Q2. How many test reports are required for Batch Test Analysis?

At least 5 test data records are required, and each individual test must be at least 3 minutes long.

Q3. Can Batch Test Analysis identify which devices have performance problems?

Yes. The analysis can identify specific devices, test cases, and performance modules associated with performance problems.

Q4. Can the feature detect crashes?

Yes. If a test case crashes or exits unexpectedly, the test failure information can be included in the batch analysis. Developers can use device information, test time, runtime duration, and memory usage as clues for further investigation.

Q5. What performance metrics are included in the batch analysis?

The performance overview includes high-level information such as FPS, memory, power consumption, temperature, and network traffic. Scenario-level performance information is also provided.

Q6. Does Poco automation affect performance measurements?

Potentially. Poco-based automation scripts used with GOT Online Overview mode may introduce additional CPU overhead. Teams should consider optimizing the automation scripts when interpreting CPU-related performance results.

About GameOptim GOT Online

GameOptim GOT Online is a cloud-based performance analysis platform for Unity game development. It helps development teams collect and analyze performance data across areas such as CPU, GPU, memory, power, temperature, and network performance.

With automated testing and batch analysis, teams can move from manually reviewing individual performance reports toward a more scalable performance testing workflow.

How Can Unity Developers Define Test Intervals and Automate GOT Online Data Uploads?

GameOptim — Wed, 23 Sep 2026 07:53:45 +0000

GOT Online now supports two new runtime capabilities: developers can upload test data through an API and use runtime Tags to define custom test intervals for report statistics. These features make it easier to integrate GOT Online with automated testing workflows and analyze performance across different gameplay scenarios.

Introduction

GOT Online has added two practical features for Unity development and performance testing:

Upload test data through an API at runtime.
Define custom test intervals with runtime Tags for interval-based statistics in online reports.

These features are particularly useful when a single test covers multiple scenes or gameplay states, or when teams want to integrate performance profiling into automated testing pipelines.

How Can Unity Developers Compare Performance Across Different Test Scenarios?

In the Overview mode of a GOT Online report, many pages provide important performance metrics such as:

Most of these metrics are calculated as averages across the entire test. This provides an overview of overall performance, but a single test may cover multiple scenes or gameplay scenarios with very different performance characteristics.

For example, one scene may have relatively low CPU usage while another may contain more complex gameplay logic and significantly higher CPU time.

If all data is averaged together, performance spikes in a specific scenario can be diluted by the rest of the test.

To make these differences easier to identify, GOT Online now supports test interval statistics.

Different gameplay scenarios can be treated as separate intervals, allowing developers to analyze performance for each interval independently.

This provides a more detailed view of how performance changes throughout a test instead of relying only on the overall average.

How Can Developers Define Custom Test Intervals at Runtime?

Scene-based intervals may not always be detailed enough.

Even within the same Unity scene, different gameplay states can produce very different performance characteristics. For example, a scene might include exploration, combat, and UI-heavy interactions.

To provide more flexibility, GOT Online introduces the UWAEngine.Tag API.

UWAEngine.Tag
public static void Tag(string tag);

Developers can call this function at runtime to mark a specific test interval.

Once a Tag is applied, it will override the original Unity scene name for the corresponding interval.

As a result, the scene name displayed in the GOT Online report and the interval statistics will use the specified Tag.

This allows development teams to define performance intervals based on actual gameplay states rather than relying only on Unity scene transitions.

For example, instead of analyzing an entire scene as one interval, developers can define separate intervals such as:

Exploration
Combat
Boss Fight
Inventory
UI Interaction

The exact Tags depend on the team's testing workflow and what they want to measure.

How Can Developers Automatically Upload GOT Online Test Data?

Performance testing is increasingly being integrated with automated testing workflows.

Many teams are combining GOT with automated testing tools to reduce repetitive manual work and make performance testing easier to run at scale.

Previously, after a test was completed, developers needed to manually click the upload button to send the collected data to GOT Online.

The new runtime upload API allows this step to be automated.

After configuring the required project and account information in advance, test data can be uploaded automatically without manual interaction.

The API is:

UWAEngine.Upload
public static void Upload(Action callback, string user, string pwd, int projectId, int timeLimitSec)

public static void Upload(Action callback, string user, string pwd, string projectName, int timeLimitSec)

The parameters are documented in the SDK documentation.

This makes the API suitable for automated testing workflows where a test can be executed, data can be collected, and the resulting performance data can then be uploaded automatically.

What Should Developers Know About the Runtime Upload API?

There are two important limitations to keep in mind.

1. The automatic upload feature is only available for GOT Online.

It is designed specifically for uploading performance test data to the GOT Online service.

2. IL2CPP compatibility

When using the IL2CPP scripting backend, the API supports Unity 2018 and later.

During the upload process, the application displays an uploading status. After the upload is completed successfully, it displays a completed status.

This provides basic feedback during automated or semi-automated testing workflows.

How Do Runtime Tags and Automatic Upload Work Together?

These two features can also be useful when building a more automated performance testing process.

A typical workflow could be:

Run automated test → Mark gameplay intervals with UWAEngine.Tag → Collect performance data → Upload data with UWAEngine.Upload → Analyze interval statistics in GOT Online

With runtime Tags, developers can define meaningful performance intervals during the test itself.

With runtime upload, the resulting data can be sent to GOT Online automatically.

Together, they reduce manual steps while making performance data more structured and easier to compare across different gameplay scenarios.

What Can Unity Developers Take Away?

The new GOT Online runtime APIs address two common problems in performance testing:

Problem 1: Overall averages can hide local performance issues.
Runtime Tags allow developers to divide a test into meaningful intervals and analyze each interval separately.

Problem 2: Manual data uploads add unnecessary steps to automated testing.
UWAEngine.Upload allows test data to be uploaded automatically after testing.

For teams building automated Unity performance testing workflows, these capabilities can make test data collection and analysis more consistent and easier to integrate into existing pipelines.

FAQ

Can `UWAEngine.Tag` be used to define performance intervals?

Yes. UWAEngine.Tag(string tag) can be called at runtime to mark test intervals. The specified Tag overrides the original Unity scene name for the corresponding interval in GOT Online.

Does GOT Online only support scene-based performance analysis?

No. Runtime Tags allow developers to define more granular intervals within the same Unity scene based on gameplay states or other testing requirements.

Can GOT Online test data be uploaded automatically?

Yes. UWAEngine.Upload can upload test data automatically after the required project and account information has been configured.

Does automatic upload support IL2CPP?

Yes. For IL2CPP projects, the upload API supports Unity 2018 and later.

About GameOptim GOT Online

GameOptim GOT Online is a cloud-based performance analysis platform for Unity game development. It provides detailed performance data and analysis across areas such as CPU, GPU, memory, Lua, and rendering.

By combining runtime data collection with cloud-based analysis, GOT Online helps development teams identify performance issues, compare different test scenarios, and support performance optimization throughout development and testing.

How Can Unity Developers Identify the Causes of GPU Pressure on Mobile Devices?

GameOptim — Mon, 21 Sep 2026 09:16:30 +0000

Summary

As mobile games continue to pursue higher visual quality, GPU optimization has become increasingly important. Differences between mobile GPU architectures can make GPU bottlenecks difficult to identify and optimize.

GameOptim GOT Online GPU Mode provides a set of tools for analyzing GPU pressure from multiple perspectives, including GPU rendering, bandwidth, rendering resources, Overdraw, and device temperature. These metrics help Unity developers move from identifying GPU pressure to locating the specific rendering workload behind it.

This article introduces the key GPU analysis features and explains how developers can use them to investigate common GPU performance issues.

Introduction

Higher-quality visuals often mean more complex rendering workloads. More geometry, textures, shader calculations, transparency, and post-processing can all increase GPU pressure on mobile devices.

At the same time, different GPU vendors and architectures expose different performance metrics, making it difficult to rely on a single indicator when investigating GPU bottlenecks.

GameOptim GOT Online GPU Mode provides several analysis modules designed to break GPU pressure down into more actionable data.

The main capabilities include:

Performance Brief: Quickly identify areas of high GPU pressure and prioritize optimization tasks.
GPU Analysis: Analyze GPU pressure from rendering and bandwidth perspectives.
Rendering Resource Analysis: Investigate how textures and meshes are loaded and used.
Overdraw Snapshot: Locate the sources of high Overdraw more easily.
GPU Temperature: Determine whether GPU workload is a major contributor to device heating.

How Can Developers Quickly Identify GPU Pressure?

The Performance Brief provides a high-level overview of GPU performance during testing.

GameOptim displays FPS and GPU Clocks and highlights GPU Bound frames with a light red background.

GPU Bound indicates a high GPU workload, where the number of GPU clock cycles required for computation is high enough that the GPU may not be able to sustain the target frame rate.

The Performance Brief also summarizes metrics from four areas:

GPU performance
Rendering statistics
Texture resource analysis
Mesh resource analysis

It also provides corresponding optimization tasks.

The purpose of the brief is not to replace detailed analysis, but to help developers quickly filter a large number of performance metrics and identify high-priority optimization tasks.

When a metric requires deeper investigation, developers can move into the corresponding analysis module.

How Can GPU Rendering Metrics Reveal the Source of GPU Pressure?

The GPU Analysis module examines GPU pressure from two perspectives: rendering and bandwidth.

The available metrics may differ between GPU vendors because GameOptim collects different parameters from different GPU architectures.

How Can GPU Clocks Be Used to Identify Rendering Pressure?

GPU Clocks is one of the primary metrics for evaluating GPU performance.

By examining the GPU Clocks curve, developers can quickly identify scenes where GPU pressure is high.

GameOptim also provides average values and performance trends for:

GPU Shaded
GPU Shader Cycles
GPU Primitive

When GPU Clocks is high in a particular scene, these metrics can help developers determine which part of the rendering workload is contributing to the GPU pressure and identify potential optimization directions.

What Is the Difference Between Shader Instructions and Shader Cycles?

Starting with GameOptim SDK 2.4.9, the Mali GPU report includes GPU Shader Instructions, which represents the number of shader instructions executed by the GPU per frame.

GPU Shader Instructions and Shader Cycles describe different aspects of shader execution.

Shader Cycles: The processing cycles required when the shader actually runs on the GPU.
Shader Instructions: The instruction operations contained in the shader.

The number of processing cycles required for the same instructions can differ between GPUs with different performance characteristics.

Therefore, Shader Instructions can help developers understand the complexity of the shader itself, while Shader Cycles provide information about the actual processing workload on the GPU.

How Can Culled Primitives Be Broken Down Further?

GameOptim SDK 2.4.9 also provides a more detailed breakdown of Culled Primitives under GPU Primitive.

Three additional metrics are available:

FacingCullingPrimitives: Number of primitives removed through facing culling.
FrustumCullingPrimitives: Number of primitives removed through frustum culling.
CoverageCullingPrimitives: Number of small primitives removed through coverage culling.

These metrics help developers understand the composition of Culled Primitives and identify rendering resources that may be causing unnecessary GPU workload in specific scenes.

How Can Developers Analyze GPU Bandwidth Pressure?

High GPU read and write bandwidth can contribute to significant heat generation and power consumption, making bandwidth an important area to investigate.

Starting with GameOptim SDK 2.4.9, Read Total is further divided into more detailed metrics.

For Mali GPUs, the report includes:

Front-end Read
LoadStore Read
Texture Read

These correspond to bandwidth used by the GPU's Tile Unit, Load/Store Unit, and Texture Unit, including reads of TileList data, vertex input attributes, Uniform data, color/depth data, and texture data.

For Adreno GPUs, Read Total is divided into:

Vertex Read
SP Read
Texture Read

These metrics similarly cover reads of TileList data, vertex input attributes, Uniform data, color/depth data, and texture data.

Why Does Cache Hit Rate Affect GPU Read Bandwidth?

For different GPU architectures, Read Total depends on the amount of data processed by the relevant GPU units per second as well as the hit rates of the L1 and L2 caches.

When the total amount of data remains unchanged, a higher cache hit rate results in a lower Read Total because more data can be served from the cache instead of being read from farther memory.

GameOptim also provides related metrics such as:

GPU Texture Filter
GPU Stall
GPU Texture Cache Miss
GPU Primitive

These metrics can help developers further investigate the source of GPU bandwidth pressure.

How Can Developers Check Whether Textures and Meshes Are Being Used Efficiently?

The more textures and meshes participate in rendering, and the more frequently they are sampled, the more likely memory usage, GPU bandwidth, and GPU Clocks are to increase.

To understand whether rendering resources are actually being used efficiently, developers can enable texture and mesh resource analysis and inspect their specific usage.

How Can Texture Resource Analysis Identify Unused Textures?

The texture resource analysis page provides information such as:

Texture memory usage
Texture count
Texture dimensions
Texture rendering utilization
Mipmap status
Mipmap sampling rate

Texture rendering utilization can help identify textures that remain loaded in memory but never participate in rendering.

Developers can then investigate whether the unused resources are related to:

Invisible rendering objects
Inefficient asset packaging
Unnecessary loading strategies
Other resource management issues

Can Mipmap Sampling Reveal Oversized Textures?

Yes. A low Mipmap Level 0 sampling rate can indicate that a texture is larger than necessary for its actual usage.

GameOptim uses a 5% Level 0 sampling rate as a reference point. If a texture's Level 0 sampling rate is below 5%, developers can investigate whether its resolution is unnecessarily high.

Reducing the texture resolution can lower memory pressure without necessarily affecting the rendered result when the higher-resolution Mipmap level is rarely used.

How Can Mesh Resource Analysis Identify Overly Detailed Geometry?

The mesh resource analysis page provides rendering utilization as well as minimum rendering density.

Meshes with 0% rendering utilization can be investigated in a similar way to unused textures.

Minimum rendering density provides another way to determine whether a mesh contains excessive geometric detail.

Rendering density represents the number of mesh vertices within an average area of 10,000 pixels.

If the value is above 1,000, the mesh may contain excessive geometric detail for the relatively small screen area it occupies.

If the minimum rendering density remains above 1,000, developers can consider:

Reducing the mesh polygon count
Applying LOD
Reviewing whether the asset needs to be rendered at its current level of detail

How Can an Overdraw Snapshot Help Locate GPU Pressure?

Overdraw represents the number of times the screen is filled during a frame.

Transparent objects can cause the same pixel to be rendered multiple times, making them an important source of high Overdraw and potentially increasing GPU workload and device temperature.

In the Overdraw Snapshot module, GameOptim calculates overall Overdraw using Fragment Shaded and a fixed resolution of 1920 × 1080.

During a GPU Mode test, developers can manually dump a specific scene to capture its detailed Overdraw information.

The Overdraw Snapshot module then displays Overdraw information for each camera in the captured frame.

The Overlay-UI (UWA) camera represents the Overdraw generated by the Overlay portion of UGUI, including UI elements that are not attached to any camera.

The module also provides an Overdraw heatmap below the chart.

Brighter areas indicate pixels that were filled more times during the current frame, meaning higher Overdraw and potentially greater GPU pressure.

By comparing the scene screenshot with the Overdraw heatmap, developers can more easily identify which visual elements are responsible for high Overdraw.

How Can Developers Determine Whether GPU Pressure Is Causing Device Heating?

High GPU workload can contribute to increased device temperature.

GameOptim records GPU, CPU, and battery temperatures, allowing developers to determine whether GPU workload is a major contributor to device heating.

If GPU pressure is confirmed as a major factor, developers can further investigate related metrics such as:

FPS
GPU Clocks
GPU Bandwidth

Power consumption is also closely related to GPU temperature and can provide another useful signal when investigating energy consumption and thermal issues.

However, GPU temperature should not be analyzed in isolation.

Because the CPU and GPU are physically close on mobile devices, high CPU workload and the resulting heat can also contribute to higher GPU temperature.

Therefore, when investigating GPU-related thermal problems, developers should also consider:

GPU performance pressure
GPU bandwidth
CPU main-thread workload
CPU worker-thread workload

A broader view can help distinguish between GPU-driven and CPU-driven thermal issues.

What Should Unity Developers Take Away?

Use GPU Clocks to identify scenes with high GPU pressure, then drill down into more specific rendering metrics.
Use Shader Instructions and Shader Cycles together to understand shader complexity and actual GPU processing workload.
Break down Culled Primitives to identify where GPU-side culling is occurring.
Analyze GPU bandwidth from the relevant GPU-unit metrics and consider cache behavior.
Check texture and mesh utilization to identify resources that are loaded but rarely or never rendered.
Use Mipmap sampling rates and mesh rendering density to identify resources with potentially excessive resolution or geometric complexity.
Use Overdraw snapshots and heatmaps to locate transparent objects and other sources of excessive pixel processing.
When investigating device heating, analyze GPU, CPU, bandwidth, power, and temperature together rather than treating GPU temperature as an isolated metric.

FAQ

Q1. What does GPU Clocks indicate?

GPU Clocks is a primary metric for evaluating GPU performance. A high GPU Clocks value can indicate that the GPU is under significant processing pressure in a particular scene.

Q2. What is the difference between Shader Instructions and Shader Cycles?

Shader Instructions represents the shader instruction operations, while Shader Cycles represents the processing cycles required when the shader executes on the GPU. The same instructions may require different numbers of processing cycles on GPUs with different performance characteristics.

Q3. Why should developers check Culled Primitives?

Breaking down Culled Primitives into Facing Culling, Frustum Culling, and Coverage Culling helps developers understand why primitives are being removed and identify potential sources of unnecessary GPU workload.

Q4. How can developers find unused textures and meshes?

Rendering utilization can reveal resources that remain loaded but do not participate in rendering during the test. Developers can then investigate whether the resources are unnecessary, incorrectly packaged, or simply not covered by the test scenario.

Q5. What does a low Mipmap Level 0 sampling rate indicate?

A low Level 0 sampling rate may indicate that the texture resolution is higher than required for its actual rendering usage. GameOptim uses 5% as a reference point for identifying textures that may warrant further investigation.

Q6. How can Overdraw Snapshots help with GPU optimization?

The Overdraw Snapshot module provides per-camera Overdraw information and a heatmap. Brighter areas indicate more pixel fills, allowing developers to compare the heatmap with the scene and locate visual elements responsible for high Overdraw.

Q7. Is high GPU temperature always caused by GPU workload?

Not necessarily. High CPU workload can also contribute to device heating, and the CPU and GPU are physically close on mobile devices. GPU temperature should therefore be analyzed together with GPU pressure, bandwidth, CPU workload, power consumption, and other relevant metrics.

DEV Community: GameOptim

How Do You Tell Whether a Unity Stutter Is From GPU Shader Cost, Bandwidth, or Thread Blocking?

Summary

What Does "GPU Is Slow" Actually Mean?

Cycles/Pixel: Reading Shader Complexity

GPU Bandwidth: Reading Memory Traffic

Timeline: Reading Thread Activity During a Stutter

How Can You Tell Which Subsystem Is Causing the Stutter?

What Should You Check First?

What Should You Avoid?

Key Takeaways

FAQ

How Do You Find the Lua Function That Is Actually Costing You Frame Time?

Summary

What Is the Core Problem?

Why Does the Cost Hide in the Call Stack?

How Is a Lua Function Identified in the Report?

How Can You Tell Whether the Function Is Actually a Problem?

What Should You Check First?

What Should You Optimize?

What Should You Avoid?

Practical Recommendations

Key Takeaways

FAQ

How Can You Tell Whether a Unity Crash Is From GPU Memory, Resource Footprint, or Mono Heap Retention?

Summary

What Does "High Memory" Actually Mean in Unity?

PSS GPU Memory: Reading the Driver's Number

The Memory Usage Page: One Table, Three Questions

Layer 1: The Overview Table

Layer 2: Per-Resource Breakdown and Snapshots

IL2CPP Mono Heap Snapshots: No Separate Mono Build Required

Reading the Heap Object Snapshot

Sampling Caveats That Change How You Read the Data

Key Takeaways

FAQ

How Large Should a Unity Mono Heap Be Before You Treat It as a Problem?

Summary

What Is the Core Problem?

Why Does a Large Mono Heap Slow Down a Unity Game?

How Can You Tell Whether the Heap Is Actually a Problem?

What Should You Check First?

What Should You Optimize?

What Should You Avoid Optimizing Prematurely?

Practical Recommendations

Key Takeaways

FAQ

How Can You Diagnose Lua Memory Issues in Unity Games?

Summary

What Are the Main Lua Memory Problems in Unity?

How Can You Analyze Overall Lua Heap Memory?

What Should You Look for in the Memory Trend?

How Can You Find the Lua Functions Allocating the Most Memory?

Step 1: Select a Frame and Inspect Allocation Call Stacks

Step 2: Use Reverse Call-Stack Analysis to Locate the Source

Why Does Lua Function Naming Matter?

How Can Lua References Cause C# Memory Leaks?

How Does the Mono Object Reference Report Help?

How Can You Identify Suspicious Object References?

What Should You Check First When Investigating Lua Memory Issues?

Which Lua Memory Analysis Tools Are Supported?

Key Takeaways

FAQ

1. Does increasing Lua heap memory always indicate a memory leak?

2. How can I find the Lua function responsible for excessive allocations?

3. Why does the Lua function's ending line number show 0?

4. Why can Lua cause memory leaks in C# objects?

5. How can I investigate destroyed Unity objects that remain referenced?

How Can Unity Developers Identify Asset Loading Bottlenecks with GOT Online?

Summary

Introduction

Main Body

How Can You Identify Asset Loading Bottlenecks in Unity?

Which Resources Should You Investigate First?

How Can You Analyze AssetBundle Loading and Resource APIs?

How Can Scene Segmentation Improve Performance Analysis?

What Does Performance Analysis Look Like Before Scene Segmentation?

How Does Scene Segmentation Change the Analysis?

What Is GOT Online, and Which Performance Analysis Modes Does It Support?

What Should Unity Developers Take Away?

3. Why does the Lua function's ending line number show `0`?

Why might Unity Profiler not show worker-thread allocations in the expected `GC.Alloc` view?