> And it's not fast either. Free() has a reputation of being > slow, and that's not surprising if you look at the way it is > almost always implemented: scanning a list of addresses in > order to amalgamate the newly freed memory with adjacent free > areas.
this is a burden for the OS, not a defect in the language. as far as the executing code is concerned, it's just releasing responsibility for the block attached to the pointer. the OS can merrily insertion sort it for all i care, but that's being handled elsewhere and isn't a function of the language. heck, the kernel could tell me that it's done within 2 microseconds and then give me an error on my next malloc because it isn't really done putting it back into place. but that's fine with me, because of the way that i use memory. i don't mind having to make friends with the OS. it follows pretty clearly-defined rules. i guess if i had some multithreaded request handler dealing with... no, i can't even imagine what i might desperately want garbage collection for. having garbage collection happen at random times would really, really make it difficult for me to profile. the reality is that the way i use memory, i know when i need it and when i need to get rid of it, and very frequently, once i've gotten all that i need, i don't need to ask for more for a really long time and can point to the exact place where i'm going to ditch it. i like knowing exactly how much memory i'm using, because i often need to use nearly all of it, for very long periods of time. how do i know how much i'm using? because everything has a very clearly defined size, and when i need more, i know that i can get it without placing an undue burden on the system (via going into swap). for me the strict typing of C means that i always know the maximal-size problem i can handle using whatever algorithm i've implemented. if i get desperate, i can pack bits. but i don't have to try to worry (or calculate) what the hell happens when i do a new(), or when some object is implicitly created or cast. sure, i could use an object-oriented language in the same way, but then i wouldn't really be using the language as its intended to be used (flexibly overloading operators, implicitly creating and casting objects from here to creation, then taking a breather from time to time to let the memory management catch up). > My personal experience is: if you can tolerate the 5-10% loss > in execution speed, a real garbage collector is invaluable. it sounds like you're working on more sophisticated code than i am, from the way that you describe using garbage collection. i'm just a speed junkie who needs to use all of my ram to do scientific computing and i don't mind counting all of my own beans. (in the real world i used perl, because development time is about 1/3 that of C. just don't try to calculate anything with it.) s. ____________________________________________________________________________________ Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/