Does game.Debris:AddItem() throttle?

[VortexColor]

Honestly this wouldn’t work if the script was deleted.

The main reason debris exists is to be 100 % sure that something will be deleted.

[VortexColor]

I think I remembered the issue wrong. Actually the problem is that if the object is already destroyed (like by another script or by falling to the void) then the code would error.

[Limited_Unique]

1/60th of a second, which for most Roblox users would be 1 frame.

[Aspecky]

I agree that debris should not be abandoned but not for the reason you mentioned, for one debris service doesnt throttle and i dont even know if throttling exists anymore, they might have gotten rid of it.

And the if statement check will always pass because the the instance variable will not just be gone after the delay has passed because that’s not how the gc works, i suspect you mean to do something like this:

local function destroy(instance: Instance)
	if instance.Parent then
		instance:Destroy()
	end
end

local function delayedDestroy(instance: Instance, seconds: number)
	task.delay(seconds, destroy, instance)
end

but even that would be redundant because the function :Destroy does that already, calling it on an already destroyed instance doesnt error or anything.

The real reason to keep using Debris is because task.delay will create a thread from the function which might be slower than what Debris internally does, another reason would be because it might destroy instances faster since it’s internal? Either way task.delay remains a nice convenience when seldom used, but for many instances the definitely use Debris

[OnceCrowned]

I would avoid using Debris since its codebase is simply old, inefficient, and outdated. Not to mention the 1000 item limit

I would switch to Debrisgobbler here: DebrisGobbler - a much more performant alternative to DebrisService

[Aspecky]

@OnceCrowned

I would avoid using Debris since its codebase is simply old, inefficient, and outdated.

These are some claims that need backing, could you please provide evidence for being all that.

[OnceCrowned]

Debris MaxItems still in effect despite being deprecated

As the title states, the MaxItems in the game service Debris still has a hardcoded limit of 1000 objects, after which any more objects assigned to Debris via AddItem is deleted beginning from the oldest object. Hence, this makes the Debris service unsuitable for handling large amounts of objects as some end up being prematurely deleted. Expected behavior There is no maximum amount of objects that can be assigned to Debris.

This game by erik cassel from 2013 using debris service

Purpose of Debris Service?

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 second…

[Katrist]

@OnceCrowned

I would switch to Debrisgobbler here: DebrisGobbler - a much more performant alternative to DebrisService

I’m not sure why you would need a whole module instead of just doing:

task.delay(2, part.Destroy, part)

Also, some of the posts you linked are outdated, especially the one named “Purpose of Debris Service”. The benchmark they used now shows that Debris is on par with task.delay.

[PhoenixRessusection (PhoenixCausesOof)]

Debris MaxItems still in effect despite being deprecated

We are likely going to deprecate Debris entirely as it has numerous implementation problems and is not more efficient (in fact, far less efficient) than the equivalent Lua code: task.delay(lengthOfTime, function() instance:Destroy() end) We recommend using this from now on instead.

This settles it.

And here I was, thinking Debris was still maintained… Why didn’t Roblox deprecate it sooner? There’s not even a warning in the documentation either…

P.S. this code does create a new thread, though. I think the best course of action that Roblox should take is just update the implementation of Debris. For now, though, Wisp has provided this workaround:

Debris MaxItems still in effect despite being deprecated

For anyone interested, I’ve come up with a pretty elegant workaround to the problem I pointed out. Since modules are effectively initialized as a unique script, we can leverage a ModuleScript to be a generator of external threads like so: return task.spawn(function() while true do task.delay(coroutine.yield()) end end) Then this generator can be resumed, to schedule new threads unassociated with the requiring script: local ExternalThread = require(Module) coroutine.resume(ExternalThread,…

[Aspecky]

His first link has a roblox staff saying Debris is bad, so a module can definitely be made to be better.

Debris MaxItems still in effect despite being deprecated

We are likely going to deprecate Debris entirely as it has numerous implementation problems and is not more efficient (in fact, far less efficient) than the equivalent Lua code: task.delay(lengthOfTime, function() instance:Destroy() end) We recommend using this from now on instead.

[Katrist]

@Aspecky

so a module can definitely be made to be better.

In the post you linked, he recommends using what I showed, not a random module. You should read the posts you link.

[Aspecky]

Dont be aggressive now, he recommends it because it’s better than Debris not because it’s the best alternative, creating a function and a thread just to destroy a single instance can definitely be avoided, and if done properly will result in major performance gains

[Aspecky]

@PhoenixRessusection

P.S. this code does create a new thread, though. I think the best course of action that Roblox should take is just update the implementation of Debris. For now, though, Wisp has provided this workaround:

This is just extra steps and doesnt solve anything, it still creates a thread, just do task.delay(seconds, instance.Destroy, instance)

[OnceCrowned]

The module is supposed to be an updated 1:1 substitution for DebrisService, which doesn’t need to spawn new threads since everything is clumped together and scheduled while avoiding the legacy roblox scheduler.

You don’t need to use DebrisGobbler or any other module for that matter, just I’d prefer to not reinvent the wheel… Unless the wheel is broken like DebrisService is

In fact, legacy DebrisService is so bad to the point where creating a new thread is more efficient. Wow…

There is no reason to create a new thread to asynchronously destroy one single item when you can just chuck thousands of instances into a queue to be destroyed synchronously.

[Katrist]

Sorry if I came off as rude.

I made some benchmarks to compare the speeds.

@OnceCrowned
Code:

local DebrisGobbler = require(game:GetService("ReplicatedStorage").DebrisGobbler.DebrisGobbler)

local start = os.clock()

for i = 1, 50000 do
	local part = Instance.new("Part")
	DebrisGobbler:AddItem(part, 5)
end

print("DebrisGobbler: ".. os.clock() - start)

task.wait(5)

local start = os.clock()

for i = 1, 50000 do
	local part = Instance.new("Part")
	task.delay(5, part.Destroy, part)
end

print("task.delay: ".. os.clock() - start)

Results:

DebrisGobler: 0.26530759999877773
task.delay: 0.17425839999850723

Apologies if there is a flaw in the benchmark, I made it in 3 minutes.

[Aspecky]

You only benched the difference between DebrisGobbler’s insertion and task.delay, there’s a fundamental difference between the two, you’ve made 50k coroutines when you did task.delay which is so unnecessary, DebrisGobbler doesnt do that and that’s what makes it a lot better when dealing with many instances.

Also, a simple bench like that doesnt take into account outliers and whatnot.

[OnceCrowned]

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

Also, it might save a few keystrokes (?)

[Aspecky]

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.

[AskWisp (Wisp)]

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.