koobas.hobune.stream
Perfomance Optimization for no longer needed objects
My main question is what would be the best optimized way to handle objects that are no longer needed in the scene.
Ie. If my camera is constantly moving positively on the z axis that means that objects that are "behind" (their z is less than the camera's z) are no longer needed and could therefore be disabled or deleted.
Would it be best to just iterate over all gameobjects on specific time steps and disable them if not needed?
Same goes for objects that are outside the camera's view, would it be better if they are disabled on start-up and enable them when they are about to come close to the camera's view-port?
I know occlusion culling works in a similar way but since that only disables the rendering of the objects, wouldn't it be best to disable them as a whole since their behaviors would still be calculated every frame even if that is not needed?
I presume that deleting them might make it hard to restart your level, but perhaps that isn't a problem. You are right in thinking that being able to say this definitely won't run will yield performance benefits over something having to work that out for you, if you know that then you should do it. You sound like you have a good handle on it to me - my two pence - delete saves more memory and performance than deactivate which saves more than disabling the renderer.
Thanks for the feedback! The way i see it we'll most probably be keeping a sorted reference to all objects in the level so they can be re enabled on restart without actually reloading the whole scene.
Another concern of $$anonymous$$e is about the garbage collection and how that could affect performance. If let's say i disable a decent amount of objects between GC cycles, will the next GC slowdown to handle all of them or are they handled automatically upon deletion.
Finally if i recall correctly I think i have read somewhere that disabling and enabling objects at run-time is kind of inefficient. Is that the case as that is how the "yet to come" objects will be handled by first being disabled -> enabled when the camera is getting close -> deleted when we are through with them.
I've heard that about enabling and disabling objects with active - the problem would be the pulse on re-enabling - I guess my suggestion on that would be try three things:
Activating/deactivating
Doing a GetComponentsInChildren and setting enabled false on the enabled property of those that have them. Plus setting is$$anonymous$$inematic on rigidbodies.
Garbage collection is worst hit by allocating lots of small objects that don't live long - because Generation 0 of the GC is often tiny at only 256$$anonymous$$B and it gets collected every time that fills up (it is variable not guaranteed at that size, and the quote is from Windows so not gospel for $$anonymous$$ono). All the objects alive at that time make it to Generation 1 which also isn't very big and fills up - you can see how this cascades with objects that aren't really long lived pushing up and ending up in larger and larger collections.
Deleting things is going to make them unreachable and hence available for collection, if they have been alive for a while then that collection is unlikely unless the memory is getting really full - manually GC when you can, including higher generations is a strategy when you know you've got the time - manually collecting only generation 0 often causes more problems by making temporary objects move to higher generations as I mentioned before.
Oh and you could try to spread things out between frames - that might be natural anyway with what you are considering, but it might be worth creating a queue of things to enable and working through it gradually, only forcing it when it would cause a visual glitch.
Great insights thanks. Good thing is i think i'm pretty much headed in the right direction and might also consider splitting the level in chunks but that will show in actual testing. Thanks again and if you want, convert your comments into an answer so i can mark it as answered correctly :)
