"The speed of light sucks." - John Carmack
Software engineers within the world of low-latency automated trading (colloquially known as "high-frequency trading" or HFT) obsess over speed. From purchasing private bandwidth between microwave towers to analyzing x86 instructions from different compiler versions, those with experience in this industry have seen colossal time and expense committed to the problem of optimizing code and network paths for minimal execution times.
But how does one actually measure how fast a program is? To the uninitiated, it sounds like a simple task. However there are many layers of complexity in measuring the true latency of a trading system, or even defining what to measure in the first place. Understanding latencies in algorithmic trading systems can present Heisenberg-esque dilemmas, where the more code you write to measure latency the more overhead you add to your program and therefore the more inaccurate your measurements become.
At Architect we have been using a combination techniques to measure the latency of various codepaths and processes that comprise our institutional trading technology suite. Let's explore some solutions to these problems.
--
Let's say you've written an algorithmic trading strategy. Your strategy reacts to market trades in an instrument, perhaps by computing a proprietary model valuation, and sends an order in that instrument provided certain conditions are met. You would like to measure the time that this reaction takes, so that you can reduce the time as much as possible. Let's use Python-style pseudocode to describe the program (although in practice it is most common to use languages like, C, C++, and Rust where optimal program latencies are required):
