Only 40 lines of code

A small change in OpenJDK—switching how thread “user time” is retrieved—wiped out a long-standing 400x performance gap, cutting the cost of the operation from roughly 11 microseconds down to about 279 nanoseconds. The fix traces back to an older JDK issue (JDK8210452) noting that getting current thread user time via one path was dramatically slower than using the CPU-time route. What made the improvement notable wasn’t just the result; it was the scale of hidden work that the slower approach performed.

The discarded implementation relied on Linux-style `/proc` data. It opened a `/proc` file for the thread/process, read a large chunk into a 2K buffer, then performed string manipulation to locate the relevant section of the text. After finding the last parenthesis, it skipped whitespace, read a fixed set of numeric fields (13 numbers), and then converted those stringified values back into numbers in user space to extract the specific timing fields needed for “user time.” The transcript emphasizes that `/proc` entries are generated on demand, so this path effectively turns a timing query into file I/O plus parsing overhead—exactly the kind of work that can balloon under measurement.

The replacement approach avoids `/proc` entirely. Instead of opening and parsing text, it adjusts internal clock identifiers (via bit-level manipulation of a clock ID) and then directly fetches the thread time through the appropriate clock mechanism. The code may still look dense—low-level systems code often does—but the key difference is eliminating the “file land” detour and the repeated string/scanf parsing cycle.

Flame graphs make the performance story concrete. In the before state, the largest portions of time cluster around file operations: opening and closing files dominate, while the actual numeric parsing work (including `scanf`) appears as a small fraction of total time. The graph suggests most time is spent shuffling through `/proc`-related activity and synchronization primitives (including fast user-space mutexes and futex-related behavior), not on the arithmetic needed to compute the timing value. After the change, the flame graph collapses: only a thin trace remains, with no broad swaths of file-handling frames.

Benchmarks reported alongside the change quantify the win: the operation drops from about 11 microseconds to 279 nanoseconds. The takeaway is less about micro-optimizing a single call and more about how measurement can expose “obvious” bottlenecks that were never obvious—like the cost of turning a timing query into text parsing. For engineers, it’s a reminder that performance problems can hide behind convenience layers, and that careful profiling can justify surprisingly small diffs with outsized impact.