How Can You Determine Whether Runtime Mesh Data Is Causing High Mono Memory Usage?
How can you determine whether the data used for runtime Mesh generation is responsible for high Mono memory usage? https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/e65ce577 616a 42a7 aa3b b8a3dd65532a.png
Start by using Memory Profiler to identify the main memory consumers in the Mono heap. If there are large amounts of Mesh related data, such as vertex, index, or matrix data, check the reference relationships to determine whether these objects are being held by map region related scripts. This can help determine whether the high Mono memory usage is related to the runtime Mesh implementation. The key point is not the runtime Mesh generation itself , but how much Mesh data is being retained on the script side to support it. For example, if the C side stores large amounts of , index arrays, or matrix data, these objects consume memory in the Managed Heap , which contributes to the Mono memory shown in the report. After the vertex and index data are submitted to a , the Mesh itself also maintains the corresponding Mesh data on the Native side. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/fd0a04c3 68c9 4d3c a433 3305de938c8c.png Therefore, if the Mesh has already been generated but the original vertex and index data are still retained on the C side, the same set of Mesh information may occupy memory on both the Managed and Native sides. This should not be simply interpreted as a fixed "2x memory" cost, but both sides should be examined rather than looking only at Mono memory. During investigation, focus on the following areas: Determine how much Mesh related data is consuming Mono memory. Check the number and actual memory usage of vertex arrays, index arrays, matrices, and other related data. Then use reference relationships to determine whether these objects are being held by map region related scripts for an extended period. Check whether managed data still needs to be retained after Mesh generation. If the Mesh no longer needs to be modified frequently after generation, check whether the original , , and other data still need to be retained. If there are no other references, these references can be released so that the GC can reclaim the objects later, rather than keeping them in memory alongside the Mesh. Check whether multiple copies of the same data exist. If the original map region data, converted vertex data, runtime Mesh, and other caches all exist simultaneously, the same region information may occupy memory in multiple forms. Also pay attention to temporary allocations during runtime Mesh generation . Frequently creating new , , and other managed objects can continuously generate GC Alloc. After the Managed Heap expands, it may not immediately shrink, which can cause Mono memory to remain at a relatively high level. As the Mono heap grows and the number of managed objects increases, the cost of GC scanning and marking may also increase. Therefore, this issue can affect not only memory usage but potentially GC time as well. If the Unity version and existing architecture allow it, you can further evaluate , , , and to reduce reliance on the Managed Heap during runtime Mesh construction. However, these are further implementation optimizations. During the investigation, the priority should still be to determine which data is consuming Mono memory and why it is still being retained by scripts over time .