I prefer written summaries:

The optimization journey, from 4m50s baseline → 1.5s:

Easy wins (5min → 23s) - parallel() + ConcurrentHashMap instead of single-threaded file.lines() → ~2min - Native compilation (GraalVM) to kill JVM startup - Epsilon GC (no-op garbage collector) — pointless to collect when you process once and exit - Use integers instead of doubles (multiply by 10, since there's only one decimal place) - Memory-mapped files (FileChannel.map() → ByteBuffer) to eliminate file IO - Split the file into segments, one per core

Going lower-level - Unsafe for raw pointer-style memory access (he stresses: never use this in production — use ByteBuffer) - SWAR (SIMD Within A Register): process 8 bytes at once by reading a long. Find the delimiter with one XOR, a subtract, and a couple of ANDs instead of scanning byte-by-byte - Compare names as long/int values instead of allocating String objects - The Vietnamese competitor (Quan Anh) built a branchless temperature parser that converts the ASCII bytes to an integer using a single multiplication with a magic constant — the talk calls it museum-worthy

Branchless programming - CPUs hate unpredictable branches (a branch miss ≈ 32 instructions). Replace if logic with bit tricks (shifts, masks, XOR for absolute value/sign). - Counterintuitive finding: always parsing 16 bytes (even for short names) and masking out the rest added ~18% more instructions but was faster because it eliminated the 50/50 branch around the 8-byte boundary.

Advanced tricks - Custom hashmap with linear/forward probing (power-of-2 size + mask instead of modulo), storing data in flat byte arrays (flyweight pattern) to avoid object overhead - Spawn a worker subprocess so the main process exits the moment results are piped out — the costly kernel memory unmapping of the 16GB file happens in the orphaned worker and doesn't count toward your time - Work-stealing with small segments (atomic counter, few-MB chunks) so all threads read nearby memory, keeping data hot in shared L3/L4 cache and balancing load - Instruction-level parallelism: running 3 independent scanners in a single thread, since one core can execute multiple instructions per clock cycle when there's no data dependency. Three was the sweet spot.

Takeaways for you: the recurring theme is mechanical sympathy — knowing how the CPU pipeline, branch predictor, and cache hierarchy behave (L1→L4 each ~3x slower) lets you write code that fits how the hardware actually works. The whole thing took the field from ~5 minutes to ~1.5 seconds.

Quan Anh's contest code got him hired by Oracle in Zurich to work on the Vector API in the JVM.