If you were to go object pool crazy, and never created any new objects after the game was loaded, would the garbage collector still naturally get called from time to time?
I could profile this in Unity Pro, but I don’t have it… yet.
I was just using a C# stopwatch to measure the time to run a System.GC.Collect(). With a blank-ish scene it takes around 3ms. I then tested putting 1,000,000 objects into an array. All subsequent GCs took 10ms to run. This does not bode well for future scaling, unless pool allocating everything would be a fix to make the GC never run.
If anyone knows the answer, it’d be greatly appreciated, thanks!
Thanks. That’s good to know. I thought the mono runtime might have to walk the heap looking at all the alive references every once in a while, which would choke everything up. But if that is postponed until an object is flagged as garbage then it sounds like you could go pool crazy and have some pretty great performance.
It’s not how much garbage there is, it’s how many allocations you have. So if you have 10,000 objects all pooled but GC is called by say, some string allocations it will hurt performance much more than if you only had 1,000 allocations. The size of memory in use and so forth is what causes GC to take shorter or longer. This isn’t fixable and at some point, GC will get collected. For the most part you can avoid it ever happening in the game loop, but if you use certain unity commands, it can happen such as Unity - Scripting API: Physics.SphereCastAll as it needs to create an array.
Also, string usage in games isn’t easily avoided - especially for certain kinds of games. Plus it is problematic once you get into networked games, to pool everything. Pooling itself can burn tonnes of ram and that’s a problem right there. I have read that Unity are working on some form of GC solution, hopefully meaning that GC doesn’t take so long per frame to collect. Having a cap on that might still result in the framerate going from say 60 to 30 but probably won’t be measurable most of the time. Here’s hoping.
I guess I could write my own string class that had a max number of supported characters and just reuse those strings in pools.
No great solution for the sphere cast though. Could maybe pass in an array for it to fill if Unity changed the API. Or alternatively implement another physics engine with a C++ plugin and just make calls to that.
Then again, if Unity would just have a C++ API alongside the current stuff, that would certainly make things easier to work with. Here’s hoping competition from UDK will force them to do that.
Edit: … and I just realized that creating a custom string class wouldn’t help as you still need to be able to interface with the Unity API. Requiring strings all over the place especially working with the GUI.
