This page documents the current public FerroMatch benchmark snapshot with hardware notes, exact commands, and caveats. Use it as a reproducible reference point, not a blanket promise.
Snapshot
The numbers below were captured on March 20, 2026 from revision v0.2.0-1-g3c91d68.
Market Context
Public comparison claims across matching engines are rarely apples-to-apples. Different systems measure different scopes: core-only, insert-only, or full door-to-door venue latency. FerroMatch is strongest today as a transparent, well-verified verified single-node core.
Open-source peer
150 ns per matching and 5M operations/sec on a single order book
Published README benchmark on older Xeon hardware; excludes network interface latency, IPC, and journaling from the latency figure.
FerroMatch is in the same broad core-latency conversation, but its current public end-to-end snapshot is still below this published top-end throughput claim.
exchange-core README
Open-source peer
2.0M to 2.5M inserts/sec
Published repository benchmark for inserts per second; presented by the project as a rough order-of-magnitude estimate.
FerroMatch’s current published 1.97M orders/sec loopback snapshot is already in the same order-of-magnitude band as this public Liquibook figure.
Liquibook README
Commercial exchange stack
sub-40 µs with a fastest 14 µs door-to-door production implementation
Public marketing claim for a production exchange platform with broader deployment, protocol, and operational surface than the FerroMatch baseline.
This is a different class of claim: full commercial production latency rather than a local benchmark snapshot.
Commercial exchange stack
sub-100 µs end-to-end via FIX and 500,000+ orders/sec through scalable segments
Public vendor claim for a modular commercial exchange stack with risk, clustering, and broader venue feature surface.
FerroMatch is not yet competing as a like-for-like commercial venue stack; its current strength is a verified single-node matching core.
Microbenchmarks
These are the exact measured ranges, taken from the local Criterion output for the current revision.
warm_insert_cancel_pair
Criterion estimate range for warm insert/cancel on the core book path.
warm_market_fill
Market-fill hot path on the same local machine and build.
warm_partial_match_then_rest_pair
Partial-match-then-rest path after the overflow-hardening hot-path cleanup.
Pipeline
The loopback throughput number is included for context, along with the exact server and client commands used to produce it.
bounded-resting loopback
Loopback stress snapshot under a moderated bounded-resting workload.
Caveats
This is a dated local snapshot, not a universal SLA or guarantee.
Measurements were taken on macOS loopback, not a tuned Linux production host.
Core pinning flags were requested during server startup, but affinity pinning did not take effect on this macOS machine.
The throughput run used relaxed inbound-admission settings to observe the pipeline rather than default protective limits.
More aggressive client counts and pipeline depth can trip the real bounded-admission safety rails before the server saturates CPU.