4 ms·
The anti-GC part of this rant is especially hard to take. I've had the misfortune of having to debug various memory allocation problems in C. That's something I
by pmccool 17y ago
The anti-GC part of this rant is especially hard to take. I've had the misfortune of having to debug various memory allocation problems in C. That's something I don't miss at all. To bag GC for performance without mentioning reliability is just wrong.
- scumola 17y agoI'm the author of the original post. It's not difficult. Get a good debugger, and you're job is easy. Use a memory allocation tracker while you debug, then switch back when you're done. It's not hard, just takes a little more time. Don't be lazy. Use ccmalloc: No recompilation is needed to use ccmalloc; simply link it with -lccmalloc -ldl or ccmalloc.o -ldl When you've found and fixed your leak, stop linking with the library and you're done. Why switch to a GC architecture because you don't want to do something easy like this?
- foldr 17y ago> It's not difficult. Get a good debugger, and you're job is easy. Easy for a sysadmin to say! How many web apps have you written in C lately? > It's not hard, just takes a little more time Yeah -- just long enough to go out of business ;)
- pmccool 17y agoI wasn't just talking about memory leaks. Memory allocation in C is a rich source of bugs. Even assuming they are "easy to fix", that's still a poor second to "never happened in the first place". GC isn't free, sure, but it has definite advantages.
- prodigal_erik 17y agoThe weird thing is how many projects resort to reference counting, which is just like GC only far more expensive (now every single p1=p2 requires two checks for null, an atomic increment and decrement, and a conditional branch around a dtor call!) and less reliable.
- jpr 17y agoAlso, reference counting can't handle cyclic structures gracefully. Just say no to it.
- InclinedPlane 17y agoReference counting can also become extremely complex (and error prone) in a multi-threaded environment.
- chipsy 17y agoIt seems to me like the endgame of most memory management problems is static buffers and pools for speed/low fragmentation, and GC for everything else; manual allocations are just too fiddly for most coders to favor them for optimization. Disclaimer: I've mostly worked in GC environments.
- lars512 17y agoYou say reference counting is far more expensive, but that's only in CPU cycles. Compare Python (reference-counted) and Java (garbage collected), and Java's memory use is 3x greater for similar programs, at least in my experience (also in the computer language benchmark game). Reference counting is a form of garbage collection, it's just eager rather than lazy, and that eagerness pays off in predictably lower memory usage.
- prodigal_erik 17y agoYou can save memory by writing a file a byte at a time rather than allocating a buffer. The reason you don't is that it's more efficient to batch that work. Well, the same is true of GC. If you have a million dead objects and a thousand live ones, doing bookkeeping for each dead object is far more expensive (in cycles and bus bandwidth) than just having a copying collector rescue the live objects and then reuse those memory pages en masse. Once your program's memory footprint is small enough to fit on the machines you're using, making it smaller takes more runtime work but has little benefit.