Andrew Hunter
Software engineer at Jane Street, working on the market data team. By background and inclination a performance engineer, with earlier experience at Google working on large-scale systems optimisation.
Hunter came to performance engineering through an operating systems course at university, where he began reading Linux kernel source alongside the syllabus and never stopped asking what lay one level deeper. Graduate research on a graph-traversal system that emulated hardware in software forced him to reason about memory controller bandwidth, parallel access latency, and cycle counts — the foundations of the hardware mental model he now calls ‘mechanical sympathy.’ He joined Google, where the scale of a hyperscaler makes infrastructure optimisation obviously valuable, then moved to Jane Street, where the problem inverts: scale is modest, but latency during a narrow window of market activity is everything.
Core positions
Performance engineering is primarily a measurement problem. Hunter distinguishes two instruments: sampling profilers (such as Linux’s perf), which build statistical portraits of where time goes in aggregate, and tracers (such as Jane Street’s Magic Trace, built on Intel Processor Trace), which capture the exact sequence of events in a short retrospective window. Each reveals things the other cannot, and choosing the right tool for the question at hand is as important as the optimisation itself.
He is sceptical of the common advice to profile before making any change. In systems where performance matters, efficient habits of mind — what he calls mechanical sympathy — should be the default, applied without profiling when the cost is low and the correctness obvious. Discipline cuts both ways: the same engineer who makes small efficient choices automatically must also resist optimising things that do not matter, because there is always more to fix than there is time to fix it.
His deepest conviction is that the most important performance optimisation is architectural: doing less work, avoiding unnecessary calls, restructuring data so the problem becomes cheaper before any code runs. Micro-optimisation of individual functions is the last resort, not the first.
In the wiki
- Andrew Hunter on Performance Engineering on Hard Mode — Signals and Threads, 28 November 2023: profiling, tracing, mechanical sympathy, OCaml performance, and the OODA loop applied to engineering iteration