3 ms·
The situation is a bit more nuanced than this. Yes, a GC intrinsically incurs an integer factor performance cost for many codes relative to e.g. optimized C++ (
by jandrewrogers 5y ago
The situation is a bit more nuanced than this. Yes, a GC intrinsically incurs an integer factor performance cost for many codes relative to e.g. optimized C++ (I’ve optimized both). However, while ownership-based safety models are a material improvement in some cases, in other cases the borrow-checker encourages materially suboptimal software architecture e.g. in cases where ownership can only be optimally evaluated at run-time. There are other deterministic safety models often used in these cases.
tl;dr: there are significant GC performance problems that a borrow-checker doesn’t solve. I can imagine cases where the performance improvement is significantly less than you might hope.
- throwaway894345 5y ago> Yes, a GC intrinsically incurs an integer factor performance cost for many codes relative to e.g. optimized C++ (I’ve optimized both) I'm guessing this performance difference isn't caused by GC but rather correlated with GC. I.e., GC langs tend to output relatively poorly-optimized code relative to the absolute beastly C/C++/Rust compilers or else idiomatic code results in objects scattered all over the heap (killing cache coherency) while idiomatic C, C++, Rust, etc tend to allocate coherent objects (objects which tend to be accessed in succession) next to each other in memory. TL;DR: No doubt a GC can be slower than manually managed memory in some cases, but it's insufficient to conclude that the entire performance gap between C/C++/Rust and Java/Go/etc is attributable to GC.
- jandrewrogers 5y agoNo, there are major classes of macro-optimizations that are impossible to implement with a GC even in theory. Some of these optimizations are idiomatic for state-of-the-art systems code. The impact on performance is integer factor.