I would never give up GC
BlitzMax Forums/BlitzMax Programming/I would never give up GC
| ||
| I complained a lot about GC, even after using it for a year, but now I would never give it up. The fact that I can't produce an invalid pointer to an object is so helpful in big programs. |
| ||
| That's the point, isn't it? I got used to it when started working with C# and now I can't stand non managed languages. It was incredibly exciting the first time I realised that BlitzMax was also a managed language. The garbage collector makes your life easier as a coder, specially when your application has been deployed to final customers and you have to deal with maintenance! |
| ||
| yes it is cool e.g. you could have a planet with 100,000 trees 3000 buildings 300 people if a death star blew up the planet all you have to do is remove the planet from the list of planets and all the trees,buildings and people go away automatically. |
| ||
| Unless you have a Heaven list and a Hell list ;) |
| ||
| If I'm correct in unmanaged languages only killing off the parent object doesn't free its children. The memory is still in use... At least that's my experience with C++. |
| ||
| Leadwerks, have you tried threads with the new garbage collector? Do you like it, do you find the GC is slow? |
| ||
| I've been testing code with the new threaded GC and it performs different. It is as fast as the other if you're not allocating lots of objects at the same time. I think it forces collection when a certain number of items have to be collected, or when a certain amount of memory is being used by collectable objects. that makes the threaded GC to perform in a different way compared to the regular one, wich has a much more agressive collection of objects. You application can seem jerky when suddently, the GC starts collecting things for you. This can be addressed by coding with 'object-reciclation' in mind and also, from my tests, if runing manually the collection on a separated thread. The only issue there is that you may expect any Delete method to be runed from a thread different from the main thread, so the code on any Delete method has to be thread safe. Also take into consideration that the threaded garbage collector takes into account cyclic object dependencies and cross referencing, wich makes it a bit more reliable than the faster regular one. |
| ||
| Thanks Ziggy, good to know. |
   |