So one of the things you need to do when you’re debugging is consider the possibility that your assumption is NOT what the problem is.
You keep assuming GC is your problem.
But take a look at that memory usage there…
Used Total… Mono: 9.1MB
Reserved Total… Mono: 68.1MB
Your program has 68.1 MB allocated of the system memory for your managed code objects.
Where as… your mesh data is 1.28GB, and your texture data is 1.02.
That is quite a bit.
Here’s the thing, you also say that your memory usage is GROWING over time. You’re showing me a static image. I cant’ see what is growing over time. I don’t know if your mesh data was smaller last frame, and larger next frame.
I asked you to look at this, and tell us which item is GROWING.
But no, you couldn’t bother yourself to even consider the possibility of doing anything. It was like pulling teeth just to get you to even OPEN the memory profiler and take a screenshot. But you didn’t read it… how I know you didn’t read it? You still think it’s GARBAGE COLLECTION that’s causing your problem. Despite the fact that the mono framework using a mere 2% of your memory!
And looking at your memory timeline, your GC usage is the lowest line on the timeline, and it’s rather constant… with a consistent tick in it that is probably your GC call.
Nothing appears to be climbing on that curve… and I get a feeling the problem you described in the OP about your memory slowly getting larger and larger isn’t accurate. But rather that you just plain out ran out of memory… which you have. You’re using 3+ gigs of memory, on a machine with 2 gigs. That would be out of memory. That’s not the garbage collector that knocks it low again when you’ve filled up the memory… That’s all the other stuff getting knocked onto disk because memory is full.
GC collects when that 68.1MB reserved is hit. Not when the TOTAL SYSTEM MEMORY is hit.
That’s not how these things work.