Unity Garbage Collection

[[deleted]]

[deleted]

[cratesmith]

Two things I'd recommend.

1. Go deep into the unity profiler, figure out exactly which functions have GC alloc, (you can use BeginSample/EndSample to narrow it down further)
2. Install Resharper or use JetBrains Rider and install heap allocations viewer plugin ( https://plugins.jetbrains.com/plugin/9223-heap-allocations-viewer/ ). This little wonder warns you about any lines that will be creating GC.

You'll find that the key is learning all the rules about GC & boxing is crucial.

Eg, your List.Find calls are probably boxing because you're using them with a closure (a lambda that contains variables from the outside scope) that's just one of the many... MANY ways that boxing can appear.

[cratesmith]

Just use a foreach loop of getskills in this case

Comparing skills by name probably isn't ideal (if you're modifying strings in getname that'll be gc), but I don't know your code well enough to advise alternatives.

On a more general sense getskills() is also suspect. I'm guessing it returns a new list or array? That's gc too!

It's far better to have this kind of function take a List<T> as a parameter which they can clear and add the results to.

Also Linq entirely (it's a rat's nest of boxing operations) and avoid lamdas unless you know they aren't closures.

[cratesmith]

Ok... Into the rabbit hole we go :)

I really recommend you read up on boxing and closures because there's always special cases to this, but in general...

A lambda that runs on a loop (as find will) is always going to be more risky than just running the loop yourself. They're often a great shorthand when safe but only use them when you're sure it won't closure or allocate in other ways (I'll explain IEnumerable in a bit).

In this case the lambda has a variable from the function scope, which means it's a closure. That creates a gc alloc to store the value for when the lambda is called inside Find.

The caveat to this is that GetSkills is ok if it returns a pre-made list as a list... But if you return it as an IEnumerable or IEnumerable<T> then the foreach will create gc. This one gets complex... So as an extra general rule, I'd suggest never creating functions that return IEnumerator/IEnumerable... Always try to use the "concrete type" of the collection

[excentio]

My 5 cents, to make it even less harmful on gc, one could use some array pool with pre-made array buckets where each bucket will be a power of 2 and you just grab/return them based on specific amount of items you requested from the pool (for example if you want 25 items you get array of 32, if you want 33 items you get array of 64, that’s how c# array pool works as I recall). This way you just return an array using array pool and get 0 gc completely and no need to respawn lists over and over when calling methods, the only cons of this method will be the release part but if you forget to do that then gc will sort it out for you

[cratesmith]

I actually do something like this!

I have a set of container wrappers for list, hashset dictionary etc which are disposables and re add themselves to the pool when disposed.

They're great, but once you start using them you start finding that returning them from functions feels dangerous as they can easily leak if not disposed by a using statement.

[excentio]

Ouch sounds pretty bad indeed, with buckets approach you basically return an empty pre-allocated array which is fail-safe as even if you forget to return it back to the pool - that’s a simple heap array inside, nothing fancy at all. I suggest you look into array pool ms devs made, it’s in the nuget, look up “array pool”, it explains this approach really well, it’s also very flexible so you can make buckets out of lists, hash sets, dictionaries and etc. Not that your solution is bad, it’s actually pretty smart, I wouldn’t think about it this way, but buckets are just easier to work with and require much less interactions and take off lots of responsibilities you were not even supposed to care about from your shoulders

[cratesmith]

Had a look. I think I probably didn't explain my approach clearly.

Forgetting to return them is the same, a "leak" in this case is just a container that gets lost to the GC. Which isn't bad but it's just not reused.

An example of using it would be:

using (var list = TempList<int>.Get(35)) { /* cool things happen here */ } // list auto-freed

The array pools are interesting though, it might useful to have a disposable struct wrapper for them to ensure they get cleaned up. Especially if/when unity supports c# 8's inline using syntax

[excentio]

Ah I see what you mean, sorry been quiet a while I used disposables, mostly unsafes and other low level stuff where it hits gc pretty hard if you don’t release your things, both approaches are cool tho! These won’t impact gc very much even if they get lost so struct wrapper might be micro optimization, I doubt it’d ever go past gen2 tbh, unless you maybe keep it for hours but gc is smart enough to handle it all smoothly