Debris:AddItem() or :Destroy()?

Help and Feedback Scripting Support
#1

Which one is better for perfomance?

#2

They do the same thing. One just delays it.

2 Likes
#3

:Destroy is better in terms of performance, but this is more of a micro optimization. AddItem throws in a delay and some extra checks to make sure it doesn’t error after the delay

1 Like
#4

:Destroy() is better, but incase you are planning to use “wait(x) Part:Destroy()” but don’t want to delay the actual script, use Debris.

#5

Debris from what I’ve heard actually uses wait therefore… yeah, it will probably be kind of bad.

My recommendation:

Get PysephDev’s custom wait, or my fork of it.
It’s gonna be great specifically if you have a lot of objects you need to :Destroy at all times.
I recommend having a module that holds your custom wait function anyway even if you don’t use a custom implementation.

And just use it using coroutines, I don’t recommend using the cooler task.spawn right now because I believe it might suffer from delay from an issue at the moment.

local Wait = require("path-to-module")
local Part = game:GetService("Workspace").Part

local function AddItem(Instance, Time)
    coroutine.wrap(function()
        Wait(Time)
        Instance:Destroy()
    end)()
end

AddItem(part)
#6

AddItem doesn’t yield, wait yields. Debris is a better option if you don’t want yielding.

1 Like
#7

Debris uses delay(), which does use a wait() as far as I know.

1 Like
#8

I know, that’s not what I meant, I meant as it using it internally.

That’s the message I got at least from Kampfkarren on Twitter talking about this, as he was critiquing wait and mentioned Debris as not good either, so /shrug

And it could just not be necessarily using wait, or delay, just something that uses whatever wait does.

#9

What I’m saying is it doesn’t yield, it doesn’t stop the code. Wait does stop the code. I’m confused as to what you’re getting at.

#10

delay() calls spawn() (which calls wait()) in a separate thread, and therefore doesn’t yield the current environment. It does however, yield the psuedo-thread by calling wait() — keep in mind, without any arguments — which is already a bad practice in itself*. This is why coroutines are preferred over the legacy methods (spawn(),delay(),AddItem()…). So while yes, you are correct about it not yielding the current thread, it still causes issues with the spawned function from AddItem().

*source can be found below

1 Like