My question is somewhat simple, is there any other way to check for a child of an instance, if I know its name/class/type, without using :FindFirstChild()?
I find it somewhat unhelpful that trying to index a non-existent child results in an error instead of returning nil, as :FindFirstChild() is very slow and not suitable in cases where I’m checking a lot of instances at once periodically.
I also thought about using pcalls on everytime I try to index the said child, and handle it depending if it catches an error or not, but while I haven’t done any testing, I expect that would be even more CPU intensive and to me it seems like a very dirty way to solve the issue.
Do you really need to run FindFirstChild() very frequently though?
FindFirstChild may be slow, but if you do it only once and cache it into a table, you can design it such that it’s only done when the speed penalty doesn’t matter.
You can also use ChildAdded and ChildRemoved to update the cache when a child fits your conditions.
Now obviously this way will cost a bit of memory, but it’s much preferable to losing out in speed.
I don’t thing using events would be appropriate, since its a kind of garbage collection script, keeping track of a lot of instances at once, and having them all connected to an event could lead into even worse performance in my opinion.
Putting them into a table and then /ndexing them to know if they’re still in the table also doesnt work, as it somehow still returns a non-existent part even when it hass been long destroyed.
The only solution that comes to my mind is to set a limit on how many times the FindFirstChild() can run on every heartbeat, but I’m unsure if that’s the right approach.
to my knowledge, to workaround “misleading” memory references, you can doublecheck if they still “exist” via their ancestry (either you could check via
game:IsAncestorOf(Instance)
-- or
Instance:IsDescendantOf(game)
You’re writing garbage collection logic for instances that you’re already destroying yourself, even though collecting garbage is exactly why you destroy instances…?
I get the context now, but I can’t understand why you’re working on GC in the first place. Can you enlighten me?
The thing is, only the descendants of models are getting destroyed, models I’m keeping track of in spatial partitioning grid for optimalization purposes, however, under some circumstances I am having difficulty keeping track of, some instances of the models get destroyed, which makes the models no longer relevant for their purpose, so I need to clean them up from the spatial grid to free memory
This kind of sounds like a code architectural problem to me - unless you want to be specific with “under some circumstances”.
My point is that you’re already handling GC by actively destroying some instances that you no longer need - what’s stopping you from deleting the models if the conditions match?
Why do you need to actively check every single instance or model to achieve GC?
No. Writing your own code will end up functionally similar to FindFirstChild, and probably less efficient than the built-in one.
If this was the case, it would run the same steps as FindFirstChild,
This is a lot more expensive operationally.
What “speeds” are you trying to achieve in this situation? This just seems like the case of micro-optimization where it’s probably not needed.
As for your garbage collection - ultimately, you cannot write your own as it is locked from developers and is only used internally, automatically. The only way you can influence it is remove any Instance references.
Also I just read this post in specific, and this is just flat out false.
ChildAdded and ChildRemoved is cheap as hell on memory. You can absolutely use this on your MODELS (not instances) to check when a child gets added or removed, and determine whether a model should also be destroyed or not.
I get the feeling that you’re overengineering things here. Hopefully this brings you back on the right track.