Descriptive Problem Summary:
After struggling with garbage collection for some hours, I've noticed that it isn't entirely my fault. It seems that the garbage collector refuses to collect objects that use range() in their functions.
Numbered Steps to Reproduce Problem:
See test case.
1. Run the program.
2. Press Get Objects.
3. The objects are still there in cyberspace when they are not supposed to be!
4. As an example of expected behavior, change range() to view()
5. Watch the magic unfold.
Code Snippet (if applicable) to Reproduce Problem:
http://files.byondhome.com/Kamuna/TestCases/ GCTestCase_src.zip
Expected Results:
Objects to be garbage collected regardless of using range() or not.
Actual Results:
Objects that use range() are not garbage collected.
Does the problem occur:
Every time? Or how often?
Yes.
In other games?
Yes.
In other user accounts?
Yes.
On other computers?
Not tested.
When does the problem NOT occur?
When not using range().
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Not tested.
Workarounds:
Don't use range!
ID:2082891
 May 11 2016, 7:44 pm (Edited on May 11 2016, 8:53 pm)
|
|||||||||||||
Not a bug
| |||||||||||||
Lummox JR resolved issue (Not a bug)
| |
Ah, it happens with hearers() too, but only sometimes. For some reason, view() is not sticking around, so that confused me. That should probably be in the reference, so people don't get confused like I did. I thought I was doing something wrong, when it turns out that I didn't need to do anything at all! Anyways, I'm happy, that means all my GC problems have been fixed, hurray!
I can see why range would do that, particularly for loops. | |
I think technically, the fact that view() *doesn't* do it is a bug. The optimization was done so that identical calls to range() and the sort would be quite a lot quicker and resource friendly. (I think, I recall discussion along those lines but it could be in reference to something else.)
view() could probably benefit from the optimization. | |
Leaving breadcrumbs. This is an interesting topic to me for reasons.
| |
But how big a deal is that, really? The object will go away eventually; it's just sitting around in a list you're not using at the moment.
[edit]
Confirmed that the range() list is sticking around while (oddly) view() is not, and that's why you're having the issue. If you call range() again at all, the old list contents are obliterated and the objs you're no longer using will be let go.
This isn't technically a bug, since the range() list works the way it does due to internal optimizations.