I’m noticing that my place has lower framerate than most games. I’ve had a similar issue in the past and it was because I was calling :Destroy() very often in my scripts, so I tried to work around it by bunching things up and destroying them in “clusters” instread of individually.
But how about Debris:AddItem()? Doesn’t it work in a similar way?
Upon checking my scripts further, it also seems like I instance tons of new things all the time and immediately destroy them.
Oof.
But I’m still interested if Debris:AddItem is any different to Destroy
They’re the exact same
The purpose of using Debris:AddItem() is to destroy objects after a non-yielding delay, their functions are identical otherwise.
Debris is good for delayed :Destroy().
Would be wise to test the studio using the performance window, which has been overlooked a few times.
Doesn’t :AddItem() use :remove() instead of :Destroy() or has that been fixed?
That has been fixed.
Here’s how I believe debris:AddItem works
Note: I’m going to be talking about soley the speed it takes to reach the point to call the destroy function, not the speed of destroy
There is a priority queue that sorts based on removal time
Every update interval (probably 30 hz) the front of the queue is checked to see if its removal time is <= current time
If it is then remove it and keep repeating this check + remove until removal time >
Removing takes O(lg n), querying top takes O(1)
So clearing the queue for all debris items to remove would be O(n lg n)
As for actually calling the function :AddItem(), it would need to insert removal time (tick()+delay arg) and the object to remove into the priority queue which is O(1)
So this means that using debris:AddItem has a complexity of O(n lg n)
Altnernatively if you were to use delay(delay arg,func()) and destroy like that, the complexity would probably(??) be The same but the fact that you are creating a thread instead of using AddItem might mean there are higher constants since add item is specific to just destroy while delay creates a new thread so it will definitely take more memory too.
But if you were to just call destroy without needing a delay, destroy is the way to go since it’s O(n) for n consecutive destroys while add item is O(n lg n)
Not to mention constant overheads or the fact that add item (I haven’t tested but this is probably true since spawn does this) delays deletion by 1/30 seconds
So if you need delay, use add item, but if you need insta delete, use destroy
IF you already have an extra thread made (wait counts) then just call destroy on that but don’t create a new thread/wait just for destroying an object
Like @Acreol probably said (sorry, only skimmed it), Destroy() is going to be very slightly faster simply because it gets straight to the point. Debris:AddItem() is going to have some extra steps to it, and just end up using Destroy() anyways.
Destroy() = You want an Instance gone asap
Debris:AddItem() = You want a small delay before destroying the Instance
They work about the exact same. Debris is more of a slowed down response, rather destroy is more of get it out of here now.
Hi. I know this is an old topic, but if anyone is reading this, there is one more useful difference to know. Debris will not error if the part is already destroyed.EDIT: Derbis will not error if the part reference has been removed (set to nil for example). This is actually quite handy, if you have multiple threads able to Destroy the same part. Instead of using pcall or Parent checks, Debris might be easier solution, if you just want to get rid of the part. EDIT: And you are not sure if part reference is valid or if the part have been created at all.
I don’t know if you are implying that :Destroy() errors if the part has already been destroyed - but, in short - it doesn’t.
In this case, the code would error as it tries to destroy an item that has already been destroyed.
If you read this little excerpt from the Wiki then what you need to know is that this is false (or at least it doesn’t act this way as of this posting). Not even Debris:AddItem errors when it attempts to destroy an item that is already destroyed.
My bad, post edited. I did not knew that Destroy will not error in that case.
They are essentially the same. What’s good about Debris Service though is that you can organize the flow of instances being instances, and the instances being destroyed. Debris simply destroys the instance you place in it after a certain time parameter. I would recommend using EtiTheSpirit’s Part Cache module for optimum performance, as CFraming parts from long distances are less performance heavy.