The Garbage Collector: Very Bad
BlitzMax Forums/BlitzMax Beginners Area/The Garbage Collector: Very Bad
| ||
| Ok, so I figured out a completely different solution to my previous thread using Types instead of Arrays However, now I've stumbled upon something that could land me in some deep trouble... the garbage collector Back when my engine was in B+ I had multiple systems that used type instances that werent permenantly refered to by a variable These systems will still use such when I convert them to BMax in B+ this wasnt a problem, when I needed the type instances I simply found them again using For..Each and all was well, but in BMax theres that garbage collector which if I understand right will gobble up my Type Instances as soon as theres no longer anything pointing at them Of course, I can turn the Garbage Collector off, but this leaves me with no safe way to get rid of type instances once I'm done with them, as soon as I call the garbage collector to get rid of one thing, or to get rid of anything else it cleans up, all of my other type instances are gone too Due to the manner in which such type instances are spawned, it simply isnt possible to keep a variable pointing at them the entire time, as soon as the instance is filled the variable used to declair them is moved on to the next instance, or removed from scope Further more, even if I can somehow convince the garbage collector to leave my anonymous type instances alone, there becomes no way for me to actualy delete them, they're stuck there in memory forever A solution to this problem is of paramount importance for my project to continue, and I simply dont see anything resembling a way around it, any help would be MUCH apreciated |
| ||
| The TList you'll need will keep them alive... |
| ||
| but... there isnt a List and since to my knowledge there isnt a way to put the type itself into a list instead of a variable pointing to it, it isnt going to help to have one There is a solution I could do using TMaps and Lists, but it would cripple the efficiancy of my engine in multiple places and I'd really rather not do it |
| ||
| in B+ this wasnt a problem, when I needed the type instances I simply found them again using For..Each and all was well If there's no list, how are you going to cycle through the objects to retrieve them?Have I misunderstood what you mean? |
| ||
| For EachIn should be able to cycle through all objects that share a type correct? Or have I misinterprited that as well? |
| ||
| In BlitzMax, you have to manually construct a list of type objects which you can then cycle through using For...Each. In BlitzPlus, this list was automatically created behind the scenes but in Max you need to create one yourself. Read the BlitzMax "User-Defined Types" tutorial in MaxIDE for more information on how to use them properly. Seb |
| ||
| I have read it, it wasnt helpful ...dear god all of the little tweaks I've made over the past 6 months to make things more efficiant are now ruined Simply to construct that list is going to require all the processing power I've freed up See the situation is that there is absolutly no way for the engine to predict how many of these type instances are going to be appearing or when The entire point of using such a method in this instance was to remove the limit on how many of them could be active at once Thus, I cannot place limits on the number of variables I have around to assign to them, I'd have to dynamicly create random variable names on the fly and take other measures to stop them colliding... thats going to require at least 2 TMaps to do You cannot possibly comprehend how crippling this is ...and then when I get on to converting some of the other systems.... and linking the damned things together ....Its all going to take such a huge performance hit Right, I'm going to have to do quite a lot of thinking, there has to be a way around this somehow |
| ||
| and since to my knowledge there isnt a way to put the type itself into a list instead of a variable pointing to it, it isnt going to help to have one I think you've got the wrong end of the stick, lists hold references to types, the reference variable you use when you call ListAddLast can be reused / discarded immediately after because the list creates it's own reference to the type. |
| ||
| Simply to construct that list is going to require all the processing power I've freed up What? That's rediculous. BlitzPlus also used a List, it just wasn't exposed to the programmer, and you could only have instances of the same types in it. You cannot possibly comprehend how crippling this is No offense, you're the one not comprehending here. To receap: BlitzPlus used an internal List to keep track of all types. In BlitzMAX this is no longer the case, but a linked list datatype (TList) is provided for you. If you only wish to use a single list to store a single type of objects this is possible too, James already has code that emulates the "old" Blitz way of doing things. (Basicly a Singleton Factory.) ....Its all going to take such a huge performance hit Lists insert at constant time complexity, and itterate at linear - it is not possible to create a faster data structure for these two purposes. Added to that that BlitzMAX is nearly twice as fast as BlitzPlus, I seriously doubt you will have any external constraints on your performance. |
| ||
| I'm must be particularly dense tonight, but I don't understand how... BMAX ...is going to be substantially slower than... BB ?? [edit] Mordax_Praetorian, try importing the above BB code into the BMax IDE to see what you get. [/edit] |
| ||
| Skidracer: Thats not something I knew, again it changes a lot thankyou very much Flameduck: Tankyou for trying but do read the post next time, having a list is not crippling, but trying to assure that the list was full of enough differently named variables to make the system work would have been I'm not stupid, I'm simply underinformed, and the documentation supplied with BlitzMax is not helpful in many cases If I were to rewrite a large chunk of the documentation and make it actualy useful, what're the chances that Mr. Sibly would accept it and use it an official release? If I'm getting tripped up by all this stuff then its likely other people will trip over the same stuff later on, it would be worth my time to prevent that from happening to others |
| ||
| Mordax, No one thinks you are stupid, we all know that the lack of a "Good" manual makes for these sort of posts. The problem is that because it leads to this sort of post, there are a lot of this sort of post. What a lot of Bmax users seem to have done about this specific thing, is make a base Type extending TList, and extended this to all their types that need a TList. (I havent done this, so no help from me) If you do a search in the threads (or if someone posts a link to one of the good anwsers), you will find some very simple code examples that I still find useful As a general rule, if you think you have missunderstood something, or it seems totaly the wrong way to work, then there is probably an anwser already on the board about it. Then you play the game of "Hunt The question" I would sudjest that a definate read would be Orientation guide for existing Blitz users |
| ||
| Dont worry, I fixed it Once I knew that I could reassign the variable I used to add the type to the list without removing the type from the list it wasnt too difficult I'm guessing if I call to remove the type from the list the garbage collector will come along and eat it in due time right? (Just making sure I havnt misinterpreted that as well) |
| ||
| No the garbage collector does not work properly with list. (or so Im told) (But I might be confusing delete() with GC) |
| ||
| The object is removed when nothing references it any more. If the last remaining reference is the list pointer then, once removed, the object will be up for GC collection. |
| ||
| Ok, thanks for clearing that up Since you've all helped so much I'll post up the guts of my animation system and an explanation of what its doing once I'm done, maybe someone will find it useful |
   |