From functional programming to assembly - the cost of abstractions....
summary
Immutable calculator code benchmarks run on OpenJDK 1.8 show ~10x slowdown versus a mutable loop, but compiling with Graal removes allocations so immutability costs disappear; investigation uses JMH for correct warmup and blackholes, JITWatch and printed assembly to confirm optimization, and Java Flight Recorder / JMC plus gc logs and jstat to find heap churn. A 2D array test demonstrates column-wise access hitting ~70% cache misses; database latency swamps micro-optimizations. escape analysis explains when allocations vanish.
AI-written summary · about
chapters (10)
- 0:00Introduction and motivation
- 1:10Why functional programmers care about assembly
- 3:59Performance myths and premature optimization
- 13:55Immutability performance analysis
- 23:43JVM profiling tools
- 35:01Monad transformers performance
- 38:52Database vs micro-optimizations
- 41:36CPU cache and memory access
- 46:18Benchmarking best practices
- 50:30Future of performance and abstractions
related talks
46mHow difficult can it be to write efficient code?
51mAbstractions Without Regret with GraalVM
45mHow difficult can it be to write efficient code?
51mJava at Speed: Getting the Most Out of Modern Hardware
48mA journey to JVM Excellence: Navigating JDKs and JVMs
48mJava 9 Performance
54mJava performance techniques The cost of HotSpot runtime optimizations
39mMemory Efficient Java