Hey guys,
I've been experimenting with this for some time. And I am probably wrong, here. But as far as my knowledge goes. Del() is used for immediate deletion. And setting the object's loc to null will let it become garbage collected when the server has time.
My main question would be how either of these work, how they differ. And if there is any performance to be gained by setting things to loc = null, rather than Del().
Thanks in advance.
ID:1474169
 Jan 18 2014, 3:16 pm
|
|
|
Jan 18 2014, 3:23 pm
|
|
Lugia319
 |
IIRC, Del() has to go through all existing references, while loc = null lets garbage collection just wipe it away without bothering.
|
As I understand it, explicitly deleting something incurs a bit of an overhead, because it has to hunt down and scrub any variables referencing the object you're deleting.
Setting loc = null will in most cases just let an object linger around until the garbage collector's next cycle, in which it'll remove it from memory. This only works if nothing else is referencing the object though, otherwise it'll just be a null location but will continue to exist in memory. | |
Giving a null loc does not delete anything. The object still exists, you just can't find it because it has no location on the map. The only way to truly use this method to completely delete an object is to null all other references to it, not just loc. This utilizes the garbage collector which searches for any object that has no references tied to it and deletes it automatically. Using this method is greatly advantageous because it does not use the resources needed for del() to do the same thing. Del() has to cycle through all of the references on its own, null them, then delete the object.
If you want a third option, I'd recommending looking into object pools and using them to recycle objects instead of creating and deleting them. Using New() and Del() a lot is very resource-intensive. | |
So if you set an object's location to null, and you do this over a run-time of say 10 days, would the server have to keep track of all of those object variables, slowing it down?
| |
Can't you also set its invisibility to 101 along with setting it's location to null to soft delete it?
| |
The only method I'm aware of is nulling all references to the object. Anything else will make it go away maybe, but it will still contribute to the object count.
| |
Lugia319 wrote:
So if you set an object's location to null, and you do this over a run-time of say 10 days, would the server have to keep track of all of those object variables, slowing it down? If you remove all references to an object, the garbage collector will destroy it. The loc is often the only reference for most objects (ie it is referenced in a turf's and area's contents list), which is why people tend to over-simplify the idea into "set its loc to null". If there are any other references to the object, it will not be GC'd. If the object has a key or tag, it won't be GC'd. If the object has a running or sleeping proc (ie the 'src' variable in the proc references the object), it will not be GC'd. Basically, so long as it thinks there's some way for the code to access the object (short of a \ref code), it won't collect it. More info on the garbage collector: http://www.byond.com/docs/ref/info.html#/DM/garbage | |
If you use del while a game is being hosted on the linux version of dream daemon, it results in a BILLION error messages.
I'm not even kidding here. | |
Most games seem to use del() instead of making good use of the garbage collector, so I'm surprised such an issue hasn't been discovered.
| |
Is there a way to see if an object got deleted? I'm currently in the process of writing a rather large source, and I've been setting everything up to delete via garbage collection and not use del() at all. I have my suspicions doing this that it may backfire in the longrun.
| |
That seems a bit tricky, since you'd have to somehow reference the object to see if it still exists or not (which would in turn make it ineligible for garbage collection).
I suppose you could do something like: for (var/atom/o) Though this isn't fool-proof as you can't really tell if o is still being referenced somewhere. | |
Ah. But the objects sitting and waiting for clean up won't cause any build-up or anything, right? Trying to gauge whether the brief overhead from del() is better or worse than waiting on the objects to be collected in the longrun.
| |
You should most definitely be using the garbage collector as much as possible. The del command is for moments where you know you'll want something to be deleted right away. Imagine you have a bullet-hell game where there are thousands of bullets flying every frame. When they collide with something, you will not want to delete it right away because you will be causing the cleanup of several objects each frame and that will take a lot of time. Instead, you want to set the loc to null and null the references out so that the garbage collector will delete them over time. Deleting objects over time is more efficient because it takes less processing power from each frame. Using the Del command in this situation would cause most frames to take too long to process and thus create "lag".
| |
Actually in that situation you'd want to use an object pool.
| |
Back here, after some sleep.
At the moment, still working on my SS13 code. And Del() is used a LOT. Currently, atom/movable/Del() is actually one of the laggiest things around. Since I pretty much got rid of everything else. But, in either case. What I got from Fugsnarf (Can't quote mid-post, I think.) Is that it'd be best to kind of create my own garbage collector of sorts? I've been thinking about doing such thing, but I was unsure if this was even worth the effort at all. Because in the end, I will still have to use Del() in the deletion process to get fully rid of it. Beside that, if loc = null keeps the objects in the memory.. Then that may be what is causing this: http://puu.sh/6qiNo.png But any way. TL;DR: I should try and make my own garbage collector, or just start looking more into the loc = null thing? | |
Why would you ignore what I just said...
Just use the built-in garbage collector. Set locs to null and null references and that's all you need to do. This method work for almost anything you could create with DM. The trick is nulling the references. | |
My main concern is that what happens if there is still references to said object? If the object is in a list, it won't be garbage collected either, because it is referenced.. Am I correct?
I'm still hoping for an assured deletion, because this: ^^ That's one SS13 server running over a 6 day period. | |
It won't be garbage collected because the object still has a reference (its contained in a list). You have to go and null all of those out.
That means heavily restructuring how a lot of things work unless you kept track of where all references occur. | |
The restructuring to make proper use of reference nulling tends to fix a lot of other issues, too, like massively reducing the 'spaghetti factor'.
| |
