How Can You Determine Whether Runtime Mesh Data Is Causing High Mono Memory Usage?
How can you determine whether the data used to generate runtime Meshes is responsible for high Mono memory usage? https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/2948b43b fc71 434a 9acf bc05f1a31bcc.png
Start by using Memory Profiler to identify the main allocations in the Mono heap. If a significant amount of memory is occupied by Mesh related data such as vertices, matrices, and index arrays, then check the reference relationships to determine whether these objects are being held by scripts related to the map regions. This can help determine whether the high Mono memory usage is related to the dynamic Mesh implementation. The key issue is not the fact that the project generates Meshes dynamically , but how much Mesh data is retained on the C side to support that process. 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 corresponding Mesh data on the Native side. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/4196711b d7bb 4155 8903 f2df1de59d7a.png Therefore, if the Mesh has already been generated but the original vertex and index data are still retained by the C side, the same set of Mesh information may occupy memory on both the Managed and Native sides. This should not be interpreted simply as a fixed "2x memory" cost, but both sides need to be considered rather than looking only at Mono memory. During investigation, focus on the following areas: Determine how much Mesh related data is stored in Mono. Check the number and actual memory usage of vertex arrays, index arrays, matrices, and other related data. Use reference relationships to confirm whether these objects are being held by map region related scripts for a long time. Check whether managed data still needs to be retained after Mesh generation. If the Mesh has been generated and no longer needs to be modified frequently, check whether the original , , and other data still need to be retained. If there are no other references to these objects, their references can be released so that they can be reclaimed by the GC 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 check for temporary allocations during dynamic 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 may affect not only memory usage but potentially GC time as well. If the Unity version and existing architecture allow it, you can further evaluate approaches such as , , , and to reduce reliance on the Managed Heap during dynamic Mesh construction. However, this is a further implementation optimization. During the initial investigation, the priority should still be to determine which data is consuming Mono memory and why that data is still being retained by scripts over time .