To be honest, speed isnt the greatest of concerns for DebrisGobbler when taking into account the overhead of spawning 50 thousand threads. But that probably isn’t a concern since the new task library is pretty efficient ngl
In my opinion, DebrisService by itself only has a few use-case advantages over simply spawning in a thread to get rid of an instance in a timely manner.
I’d say that the biggest advantage of modules like DebrisGobbler is for large-scale projects. For example, if you have a thousand primitives that spawn at inconsistent times, and each primitive has to be removed in a random amount of time, thats when you’d probably want to use DebrisGobbler over making a thousand task.delay calls
A roblox staff recommends to not use Debris service because it’s not efficient.
So just do task.delay(seconds, object.Destroy, object), but if you have many instances it should be better to use dedicated module that doesnt create a thread for every object like DebrisGobbler.
To be clear, every thread is associated with the script which created it. When a script is terminated, these associated threads are canceled. Because of this, Roblox’s recommended workaround, is not actually 1:1 with the functionality of Debris:AddItem–which will still run the cleanup, regardless of whether or not the calling script lives long enough to see it.
Those “extra steps”, are for addressing this very important caveat.
(?)