We are looking into this issue.
Would using the NativeArray collections for temporary data be an alternative for you? They are a thin wrapper around a buffer of native memory and do not use Garbage Collection. Instead you can immediately free their memory using the Dispose() method. They also offer control over the allocator so you can allocate memory with different lifetimes.
Hi, thanks for looking into it.
We already optimized largest RAM allocations using NativeArray. Also optimized max RAM usage by a lot. I found this bug by accident when testing GC API on web builds.
But the project is huge and it is impossible to track and optimize everything at this stage.
In some cases reducing total RAM usage means we use lighter pooling setup that causes more allocations overall, which probably triggers this GC bug even more.
We’ve also been having similar issues with our application regularly crashing on desktop and mobile web after long periods of regular usage or short periods of intense use, especially loading 3d models from GLB/GLTF files. We were using Piglet to load these files. When we reached out to see what could be causing this issue, Unity support said that it could be a problem with that plugin, so we switched to Unity’s first-party GLTFast plugin, but that didn’t seem to help with the memory issues. Models load slightly faster, so at least it wasn’t a total bust, though
@MarcelPursche I would also like to ask for prioritization of this issue - this one causes our web-based app to crash consistently, with no way for us to fix it on our side.
Bad news for those waiting a solution for (UUM-86352).
Unfortunately, there is no way to free memory from unused (Resources.UnloadUnusedAssets) textures, materials and meshes properly without GC unless they are addressables.
We are fetching a lot of GLB files remotely with textures in them. We are culling GLBs by camera frustrum and need to destroy each object out-of-frustrum; otherwise, the browser is throwing OOM. That’s why manual GC is crucial in our case. Caching those GLBs is out of option since we are not the provider.
Bad news for those waiting a solution for (UUM-86352).
Even worse news for those waiting for a solution: They’ve marked this bug as “by design”.
@MarcelPursche Given that it has been determined that this issue is not going to be fixed, what options do we have going forward to actually make our app function without running into out of memory issues with normal, ordinary usage?
The state that Unity 6 is in makes the Web platform a ticking timebomb and unreasonable for anything more than hobbyist use. The literal only way to prevent our app from crashing is asking the user to limit the amount of time they spend in the app to a few minutes - which is the opposite of what we want our customers to do.
What options do we have to make our web builds work as intended again?
