DEV Community: GameOptim

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.

Optimizing Canvas.BuildBatch Cost via Static/Dynamic UI Separation

GameOptim — Thu, 17 Sep 2026 06:52:11 +0000

Problem / Scenario

After optimizing DrawCall and Overdraw on a weapon UI panel, the rendering side looked good. But CPU profiling revealed a significant logic-side bottleneck: Canvas.BuildBatch was taking too long, causing the main thread to stall waiting for the worker thread.

What We Observed

We used GOT Online (GameOptim's performance optimization tool) for profiling, as Unity Editor's built-in Profiler adds its own overhead which can skew results.

After a 10-minute test, under Engine → UI, we found:

Rendering.EmitWorldScreenspaceCameraGeometry: 0.43 ms CPU cost

Understanding the Signal

EmitWorldScreenspaceCameraGeometry is a low-level UGUI rendering function that executes after Canvas.BuildBatch completes on the worker thread. High cost in this function on the main thread indicates that BuildBatch on the worker thread is the actual bottleneck—the main thread is waiting.

This is a useful diagnostic shortcut: if you see high EmitWorldScreenspaceCameraGeometry time, BuildBatch is your culprit.

Root Cause Analysis

The weapon UI panel had a grid of weapon icons (static) plus several rotating circular background elements (dynamic). All lived under the same child Canvas.

The problem chain:

Rotating circles change their transform every frame
Changed elements are marked as dirty
Canvas.BuildBatch must rebuild batches for the entire Canvas, not just the dirty elements
Static elements (icons, backgrounds, frames) get re-batched every frame despite never changing
The more elements on the Canvas, the more expensive each rebuild

This is a classic case of paying for work you don't need.

Optimization: Static/Dynamic Separation

The principle is simple: put elements that change at different frequencies on different Canvases.

Implementation

We split the UI into two Canvases:

Dynamic Canvas: only the rotating circle elements
- Rebuilds every frame
- Small element count → fast rebuild
Static Canvas: weapon icons, frames, backgrounds, all non-animated elements
- Rarely rebuilds (only when content actually changes)
- Large element count → but almost never rebuilt

Why It Works

BuildBatch cost scales with the number of elements on the Canvas. By isolating frequently-changing elements to their own small Canvas:

Per-frame BuildBatch processes far fewer elements
The large static Canvas rarely triggers rebuilds
Total BuildBatch work across both Canvases is dramatically less than one Canvas rebuilding everything every frame

Result

After the change:

Rendering.EmitWorldScreenspaceCameraGeometry: 0.43 ms → 0.09 ms
~79% reduction in BuildBatch-related main-thread cost
The main thread is essentially no longer waiting on the worker thread

Key Takeaway

Static/dynamic separation is one of the highest-impact, lowest-effort UGUI optimizations when BuildBatch is a bottleneck.

How to diagnose:

Profile with a device-side tool (GOT Online or similar) for accurate numbers
Look for high EmitWorldScreenspaceCameraGeometry cost
This correlates with slow Canvas.BuildBatch on the worker thread

How to fix:

Identify elements by update frequency (static, occasional, every-frame)
Group same-frequency elements on the same Canvas
Minimize the number of elements on frequently-updated Canvases

Trade-offs to consider:

More Canvases add management complexity
Elements on different Canvases can't batch with each other (potential DrawCall increase)
Each Canvas has small fixed overhead

In practice, when BuildBatch is a real bottleneck, the CPU savings almost always justify the trade-offs.

UGUI Overdraw Optimization: Tight Meshes, Transparent Culling, and 9-Slicing

GameOptim — Tue, 15 Sep 2026 07:11:38 +0000

Problem / Scenario

Overdraw—pixels drawn multiple times by overlapping UI elements—is a major source of GPU cost in UGUI, especially on mobile devices. For a weapon UI panel with circular backgrounds, item frames, and hidden selection states, the Overdraw was visibly high when viewed in Unity's Overdraw mode. The goal: reduce Overdraw without changing any visual output.

What We Observed

Using Scene view's Overdraw shading mode, we identified three problem areas:

Background circles — very bright, indicating high Overdraw from full-quad meshes
Selected-state backgrounds — elements hidden via Alpha=0 still contributing to Overdraw
Weapon item frames — hollow frames drawing full rectangles of mostly transparent pixels

How to Analyze It

Overdraw mode color intensity correlates with the number of times pixels are overdrawn:

Dark/black: no Overdraw (drawn once)
Bright colors: high Overdraw (drawn many times)

For each bright area, we asked: is all this drawing necessary? In all three cases, the answer was no.

Optimization Techniques

1. Tight Mesh for Sprites with Transparency

Problem: Circular and irregular sprites use rectangular (quad) meshes by default. The transparent corners and edges of the quad are still rasterized, wasting GPU fill rate.

Solution: Use Unity's Tight mesh generation.

Steps:

Select sprite asset → Inspector → Mesh Type: Tight
On Image component → Use Sprite Mesh: enabled
Adjust Extrude Edges parameter to control mesh polygon count

How it works: Unity generates a polygon mesh that tightly wraps the visible alpha contour of the sprite. Fully transparent areas are excluded from the mesh entirely, so they never reach the rasterizer.

Polygon count tuning: The default Tight mesh can be quite dense (many vertices for smooth contours). Reducing Extrude Edges lowers vertex count while maintaining visual quality. For our circular sprites, a value of 6 produced clean results with minimal polygons.

2. Cull Transparent Mesh for Alpha=0 Elements

Problem: UI elements hidden by setting color.a = 0 are still submitted for rendering. The mesh is built, the draw call is issued, and the fragment shader runs for every pixel—all producing nothing visible.

Solution: Enable Cull Transparent Mesh on the Canvas Renderer component.

When this option is enabled and the element's final alpha is 0, Unity culls the entire element from rendering. No vertices, no draw call, no Overdraw.

Limitations:

Only works when alpha is exactly 0
Fading animations (alpha from 1 to 0) still render during the transition
Only the final element alpha matters, not parent canvas group alpha

3. 9-Slicing for Hollow Frame Sprites

Problem: Frame/border sprites have large transparent centers. The default mesh covers the full rectangle, including all that empty space.

Solution: Use 9-slicing with Fill Center disabled.

Steps:

Open the sprite in Sprite Editor
Drag the 9-slice border handles inward to match the inner edge of the frame
Apply changes
On Image component → Image Type: Sliced
Disable Fill Center

How it works: 9-slicing divides the sprite into 9 regions. With Fill Center disabled, the center region produces no geometry at all—only the 4 corners and 4 edges generate vertices. The result is a frame shape with no center fill.

Root Cause

The common thread across all three techniques: UGUI draws more pixels than necessary because it defaults to simple rectangular meshes and renders even fully transparent content. Most Overdraw in UGUI isn't from UI elements overlapping each other—it's from individual elements drawing invisible pixels.

Key Takeaway

Overdraw optimization in UGUI mostly comes down to "don't draw what the player can't see." Three techniques cover the vast majority of cases:

Technique	Best for	Effort	Impact
Tight Mesh	Circular/irregular sprites	Low	High
Cull Transparent Mesh	Elements hidden via Alpha=0	Very low	Medium
9-Slicing (no Fill Center)	Frames, borders, buttons	Low	High

All three preserve visual quality while reducing GPU fill rate usage. They should be standard practice in any UGUI project targeting mobile devices.

DEV Community: GameOptim

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?

FAQ

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

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

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

Q4. What is scene segmentation in GOT Online?

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

Q6. Which performance analysis modes does GOT Online support?

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

Summary

How Can You Detect Frequent GC Calls in Unity?

How Can You Identify CPU Performance Hotspots More Quickly?

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

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

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

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

What Should Unity Developers Take Away?

FAQ

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

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

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

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

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

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

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?

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