3 ms·
As much as I think immutable-by-default is a good idea for code correctness, it does have a really big performance penalty since it means a LOT of GC pressure (
by overgard 10y ago
As much as I think immutable-by-default is a good idea for code correctness, it does have a really big performance penalty since it means a LOT of GC pressure (since you have to make a lot of allocations). Side effect free is great, but, at the moment anyway you can't really do it in real time systems where a GC pause is a huge problem
- tormeh 10y agoA lot of those deallocations should be easy to figure out by a compiler, though. Maybe the JVM can accommodate a delete instruction? If I say list(1,2,3).par.map(x=>x*x) there's a couple of intermediate objects that can immediately be deallocated. The GC shouldn't be bothered with cases that are so obvious.
- Roboprog 10y agoBeside generational GC, I also forgot to mention escape analysis, which sounds like what you are leading up to.
- Roboprog 10y agoAs always, there's a spectrum of problems that require increasingly lower level grunt work to be fast "enough" (or rather, "performant", as The Management likes to say these days) However, to me at least, it makes sense to start at the top and work your way down when bottlenecks arise (systems level software aside): Configuration -> DSL -> scripting -> "FP on VM" -> "(mutable) OOP on VM" -> "traditional 3GL (with bounds checking)" -> C -> assembler -> hardware. Generational GC should take most of the pain out of immutable temp value churn. You can also use libraries and frameworks that "ask nicely" to mutate things, such as behind-the-scenes internal accumulators for filter/map/reduce type operations.