3 ms·

I like that it can be used as a leak detector! I'm not sure I understand the point beyond that but then again I am in love with RAII semantics so I'm probably a

I like that it can be used as a leak detector! I'm not sure I understand the point beyond that but then again I am in love with RAII semantics so I'm probably a bit biased here.

vidarh 11y ago
Consider it a safeguard. One one hand it can detect (some) leaks. On the other hand if/when your app leaks it can mitigate the consequences of those leaks. For some very specific types of apps it can also be sufficient to ditch traditional C/C++ memory management, and you can actually even gain speed doing so. Consider e.g. code that runs a job. Most of the time you know it will need less than 32MB (or whatever) total over the (short) lifetime of the process. So you tune the GC accordingly to not trigger any collection at all until above that level. Now most of time, a collection will never get triggered, and you're happy - all the memory is just returned to the system at the end in one swoop. But if occasionally a job requires lots more, the GC may provide sufficient cleanup to still make it viable not to include any memory management. My first large CGI-era webapp was in C++ and relied exactly on lots of hacks like deferring all memory de-allocation until exit to improve performance (and it worked very well - it had a considerable performance impact; other hacks included static linking to drastically cut the loading cost). We didn't use a GC; instead we had to take extra care when we knew we were going to make large allocations to do manual de-allocation in those cases if the request was potentially long-running. I'd have loved to use the Boehm GC for that.
- pjmlp 11y ago
  Walter Bright uses this trick in his D compiler. Memory is not freed, just by the OS. http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941?queryText=Walter%2BBright http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over...

I like that it can be used as a leak detector! I'm not sure I understand the point beyond that but then again I am in love with RAII semantics so I'm probably a bit biased here.

vidarh 11y ago

Consider it a safeguard. One one hand it can detect (some) leaks. On the other hand if/when your app leaks it can mitigate the consequences of those leaks. For some very specific types of apps it can also be sufficient to ditch traditional C/C++ memory management, and you can actually even gain speed doing so. Consider e.g. code that runs a job. Most of the time you know it will need less than 32MB (or whatever) total over the (short) lifetime of the process. So you tune the GC accordingly to not trigger any collection at all until above that level. Now most of time, a collection will never get triggered, and you're happy - all the memory is just returned to the system at the end in one swoop. But if occasionally a job requires lots more, the GC may provide sufficient cleanup to still make it viable not to include any memory management. My first large CGI-era webapp was in C++ and relied exactly on lots of hacks like deferring all memory de-allocation until exit to improve performance (and it worked very well - it had a considerable performance impact; other hacks included static linking to drastically cut the loading cost). We didn't use a GC; instead we had to take extra care when we knew we were going to make large allocations to do manual de-allocation in those cases if the request was potentially long-running. I'd have loved to use the Boehm GC for that.

pjmlp 11y ago
Walter Bright uses this trick in his D compiler. Memory is not freed, just by the OS. http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941?queryText=Walter%2BBright http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over...