Optimize the RecastNavmehModifer OnEnable with initial capacity and batching?

Hello,

Currently we have about 850 RecastNavmeshModifier’s in a level. When the level is loaded in a build this causes about 238 KB of GC allocation, and 13ms for all of their OnEnable methods to running, adding the the component to the AABBTree. Hot terrible of course, but does add up.

According to the deep profle in editor, it looks to mostly be from having to rebuild the tree (ms) and expand the tree (GC).

It would be nice if we could initialize the capacity of the AABB tree. And while maybe more niche, some way to batch or otherwise prevent the rebuilding of the tree while a lot are being added at once and then re-enabling it.
A perhapse overly simple approach would just to have a static bool and list that when the bool is enabled they are added to the list instead of the tree, and then after disabling it rebuilds… or something like that.

Thanks

Hmm I’ll tag Aron to take a look at this. I think he’d be able to give a more insightful answer to this than I could.