Thanks for addressing this @suxiangting . I took a deeper look into Light2D.cs yesterday, and discovered that the culprit for the original 136bytes of garbage I pointed out was only occurring when in the editor with the call to Light2DManager.UpdateSortingLayers. It’d be really nice to be able to disable this since it has a significant performance impact in the editor, and also causes unnecessary time tracking down garbage when using the profiler (I’m sure I’m not the only one that has done this). A couple other findings are that calls to LightUtility.GenerateParametricMesh result in about 500 bytes of garbage per call, Light2D.get_lightMesh has a constructor that causes an allocation, and caching Light2D.boundingSphere then setting the BoundingSphere’s properties rather than using a constructor will eliminate Light2D.UpdateBoundingSphere’s allocation entirely. I’m sure there’s more, but this is what I was able to dig up yesterday relatively quickly. It doesn’t seem like much, but in a small scene I have >1k Light2D objects, while in a more medium sized scene I have over 4k Light2D objects. On top of that I have Light2D objects on projectiles which get ejected into the scene pretty liberally. So knocking out all those little allocations helps, thanks!
One more quick request, would it be possible to expose Light2D.m_ApplyToSortingLayers? Currently it’s private, so users of the Light2D API can’t get or set the sorting layers on Light2D objects programmatically (unless I’m missing something) without using reflection. There’s a thread about this here . I ran into this issue yesterday when I wanted to remove a sorting layer, and needed to identify which Light2D objects are using it. If I could call get on that field then I could write a method to recursively identify which Light2D objects need updating prior to removing the sorting layer. Thanks!