Collector - Lightweight, uncapped Debris alternative

Resources Community Resources
#1

Collector

Around 5 to 7 months ago, I wrote this module due to my issues with Debris being capped at 1000 objects in ~20 minutes while at lunch break. Its original (internal) name was “Debris2”, but for the sake of not causing confusion, I’ve renamed it before releasing.

Without further ado, here it is! The API is virtually the same as Debris. :slight_smile:

P.S:
I’d love to see people benchmark this and compare it to Debris itself, if anyone has the time to do that feel free to reply letting me know how it goes.

12 Likes
#2

Question, in what use case did you need to use Debris for over 1000 objects?

#3

Couldn’t you literally just do
task.delay(time, function()
obj:Destroy()
end)

#4

i mean, yeah

but having an entire modulescript dedicated to solving a problem that has already been solved seems like a drastically better idea!

#5

This is actually extremely useful for me, I was running into issues related to the arbitrary limit of 1000 objects debris. I supposed the stars aligned for something like this to be made! Thank you!

#6

Couldn’t you literally just do
task.delay(time, function()
obj:Destroy()
end)

but having an entire modulescript dedicated to solving a problem that has already been solved seems like a drastically better idea!

Why use up more resources? Roblox has a hardcoded ~2-3gb RAM usage limit.

2 Likes
#7

Question, in what use case did you need to use Debris for over 1000 objects?

I was making a 3D particle effect using custom physics, it stuck stains to the hit part for a few minutes before despawning.

2 Likes
#8

I was just trying to give a simplified version of the entire script, IMO you shouldn’t use these kinds of modules since they solve literally nothing.

#9

The main idea is performance over using multiple coroutines and Debris itself, plus repeating the same four lines of code across multiple scripts won’t make life much easier. :stuck_out_tongue:

#10

Decided to do some runtime benchmarking and your module is definitely much faster.

Here are the test result averages after running each on 900 Instances over the course of 50 different tests on my computer:

FASTEST
Collector Module average runtime: ~0.0000007 seconds (7 zeros)

SECOND FASTEST
task.delay/Destroy() average runtime: ~0.0000026 seconds (6 zeros)

SLOWEST
Debris average runtime: ~0.0000038 seconds (6 zeros)

Even though this is fractions of a second, your module’s AddItem Method Runtime is on average, 4-5 times faster than the regular Debris AddItem.

Furthermore, this module is much more precise when deleting instances when compared to Debris since this module utilizes the task library, while Debris doesn’t.

In conclusion, this is just as you say, it’s a lightweight, uncapped, and also fast Debris alternative. Great work!

6 Likes
#11

couple of other debris modules are just purely inefficient where debris:additem remains the victorious one in the end, there’s barely any well prominent debris modules and this is even more unusable.

#12
#13

I tried using debrisgobbler but it just created the largest table and when i tried to look into it in luauheap it froze my game indefinitely, even tho there aren’t supposed that absurd uses for such large table which proves debrisgobbler is more inefficient than debris service, Task library can also be memory costly and affect the library’s performance.

#14

DebrisGobbler uses a specialized data structure, which is probably the cause.

The task library will inevitably spawn a new thread.

Wanna try implementing it yourself? How about multi-threading by using a SharedTable?

#15

It isn’t maintained so i will keep using the superior debris service!

#16

Based and red pilled.

#17

nah u just ridin me til here lol, overall the debrisgobbler just had to be simpler rather to be inefficiently pointless

1 Like