What are the benefits of using the Debris
service over Destroy()
for removing temporary objects? I believe I read on it a little ago, something about garbage collection…?
wont error if that object is already destroyed.
i use it when i want something destroyed, but dont want to create a separate coroutine to destroy it after a certain amount of time
Debris service scedules the deletion of an instance in parrelel with the rest of your code so you don’t have to spawn a new thread
Do note, :AddItem()
does throttle (Meaning the time it takes to resume could be 1/60s to 1/30s), so as a rule of thumb you should only use it if you’re only concerned that the instance gets deleted sometime in the future. If you’re looking for precision use
task.delay(num,game.Destroy,instance)
This is a misconception, calling :Destroy() on an already Destroyed instances does not throw an error, what you’ve probably seen was an error for the instance not existing because it was garbagecollect’d (Same would happen with Debris)
Calling :Destroy()
on an instance after it’s already destroyed also won’t error, so I’m not sure this is important to distinguish, even though the documentation’s section about usage mentions this.
The conclusion in the docs states,
Debris does not yield the current thread, does not require a new thread and will not error if the object is already destroyed. For this reason it is the recommended method for cleaning up objects with a fixed lifetime.
Personally, I avoid using this service. It seems to me like it’s a legacy service that doesn’t serve much of a purpose anymore.
local Debris = game:GetService("Debris")
Debris:AddItem(instance, 3)
task.delay(3, function()
instance:Destroy()
end)
These seem to be functionally equivalent to me.
like @maycoleee2231 said. it will error if it is garbage collected. debrisservice solves this issue. in fact, it is one of its main selling points Debris
also, @maycoleee2231 i am almost 99% sure that debris will not error on stuff that is garbage collected. if it did, then passing nil in Debris:AddItem(3, nil) would error which it does not.
It won’t get garbage collected if you’re holding a reference to it inside your delayed function that is scheduled to clean it up, so I’m still not convinced that’s a legitimate selling point.
thats just one point. Etayt listed the other reason. also to each their own, i like convenience so I use Debris.
Debris:AddItem(item, 3)
is one line vs
task.delay(3, function()
instance:Destroy()
end)
edit: accidently used debris:AddItem(3, item) and not debris:AddItem(item, 3)
Here’s a 1-liner for task.delay
No line for :GetService() required!
Though it’s calling a :
method with .
which is a bit awkward)
task.delay(3, instance.Destroy, instance)
Talkin bout Syntactic sugar homie.
That seems to be the best reason to use DebrisService:
A developer may find it more readable than other alternatives.
I’m not aware of any other benefits.
game:GetService("Debris")
automatically deletes the oldest part assigned to it if the number of assigned parts exceeds the MaxItems
property which, according to opening a new place and using the command line to see the MaxItems
property, is 1000. This makes it easy to keep your game’s performance in check.
Note: The Old API reference manual says the MaxItems
property is deprecated but can still be changed via studio.
Do note,
:AddItem()
does throttle
source please? I’ve been looking around and i’m not able to find any evidence for this claim, i’d really love to know how you know this and where it came from
cc. @MysteryOfHyper
This topic is very old but I just came across something and it’s certainly relevant to this topic.
Debris is significantly slower than task.delay, with or without an anonymous function which is another reason not to use it. While you should be passing arguments as task.delay(time, instance.Destroy, instance), you can also just create a function inside and you’d still be saving time.
If you’re parenting parts to the workspace, my findings are that you can save 0.0335 seconds per 2,000 parts by using task.delay without an anonymous function or task.delay with anonymous function to save about 0.024. Relatively speaking, that’s about 1.6x slower.
If you aren’t parenting the parts to the workspace, the difference is even bigger, my findings show that using debris is ~1.93-2.32x slower than using task.delay.
Using 50,000 iterations, the odds skew even more. That’s a 40x difference for using it without an anonymous function and a bit less than a 28x difference for using an anonymous function.
Bear in mind that in my tests I even cut debris some slack by excluding the :GetService call from the tests. If I had included it, the difference would have been even bigger (albeit negligibly).
Don’t use Debris.
Testing code:
local debris = game:GetService('Debris')
local init = os.clock()
for i = 1, 50000 do
local p = Instance.new('Part')
debris:AddItem(p, 1)
end
local _end = os.clock()
print('Debris took', _end - init)
task.wait(5)
local init = os.clock()
for i = 1, 50000 do
local p = Instance.new('Part')
task.delay(1, p.Destroy, p)
end
local _end = os.clock()
print('task.delay took', _end - init)
task.wait(5)
local init = os.clock()
for i = 1, 50000 do
local p = Instance.new('Part')
task.delay(1, function()
p:Destroy()
end)
end
local _end = os.clock()
print('task.delay (using anonymous function) took', _end - init)
This is pretty cool, but I’m going to be honest with you. I’m not using debris 2K times or even 50K times. I use debris every once in a while primarily for objects that could be nil just so it won’t error. Yes, I could use an if to check for it and wrap it inside a task.delay, but why? I am not saving a whole lot of time by doing so. For me, the convenience outweighs the time saved.
Its fine to use debris if you’re deleting 1-10 parts every few minutes, but in my case when i was making a blood engine i spawned lots of blood drops and when they collided i used the debris service to delete them, but they were not being deleted, only after around ~6 seconds.
your test code only tests adding the instance to the delay not once the delay ends
here we can see that while debris is slower when adding the items it is quicker when destroying the items
so this shows that performance wise there close to each other debris might be a tiny bit quicker
this is the code I uses to look at the microprofiler
local debris = game:GetService("Debris")
while true do
task.wait(2)
debug.profilebegin("Debris")
local t = os.clock()
for i = 1, 5000 do
local folder = Instance.new("Folder")
folder.Parent = workspace
debris:AddItem(folder, 1)
end
t = os.clock() - t
debug.profileend()
print("Debris", t)
task.wait(2)
debug.profilebegin("Delay")
local t = os.clock()
for i = 1, 5000 do
local folder = Instance.new("Folder")
folder.Parent = workspace
task.delay(1, folder.Destroy, folder)
end
t = os.clock() - t
debug.profileend()
print("Delay", t)
end
MORE SCREENSHOTS
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.