CppTrader: matching engine, order book and ITCH handler in C++

Three components, not a platform

The project description calls CppTrader a set of components for building a trading platform, and the README lists what is in the set: an ultra fast matching engine, an order book processor and a NASDAQ ITCH handler. That is the entire scope, and it is worth being clear about it before anything else, because the name suggests more.

What you get is the performance-critical core of a market data or order handling system. The ITCH handler parses the NASDAQ feed, the order book processor maintains the book, and the matching engine pairs orders. Everything around that, connectivity to an exchange, order routing, risk checks, position keeping, persistence, a user interface, is yours to build.

The repository layout backs that reading. include/ holds the headers that constitute the public surface, source/ the implementation, performance/ the benchmark programs, examples/ three small programs, one each for the ITCH handler, the market manager and the matching engine, tests/ the test suite, and modules/ for optional pieces. A Doxygen API reference is published, and the top-level files include a CLAUDE.md and a TODO.md, which is an unusually open pair of documents to find in a trading library.

Building across seven toolchains with CMake

CppTrader is cross platform, and the CI badges enumerate the matrix: Linux with clang, Linux with gcc, MacOS, and Windows through Cygwin, MSYS2, MinGW and Visual Studio. Seven build configurations, each with its own workflow file under.github/, and a release badge driven by semantic versioning.

The requirements are cmake, gcc, git, gil and python3, with clang, CLion, Cygwin, MSYS2, MinGW and Visual Studio listed as optional. On Linux there are two system packages to install first:

sudo apt-get install -y binutils-dev uuid-dev

The build itself is driven by a script in the build directory, and the platform selects which one. On Linux and MacOS it is the same script:

cd build
./unix.sh

On Windows the choice splits by toolchain, with unix.bat for Cygwin and MSYS2, mingw.bat for MinGW, and vs.bat for Visual Studio. The build directory is not in the repository listing, which suggests the scripts create it. CMakeLists.txt at the root is the actual build definition.

gil update is part of the checkout, not an afterthought

The dependency on gil, a git links tool from the same author, is unusual enough to explain. The setup sequence in the README is three steps, and the third is the one that trips people up:

git clone https://github.com/chronoxor/CppTrader.git
cd CppTrader
gil update

The gil tool is installed with pip3 install gil, and the repository contains a .gitlinks file, which is the marker for a git-links based dependency setup. The other submodules are not fetched by git clone alone, so a checkout without the gil step will be missing code and the build will fail in a way that does not obviously point at the missing dependency.

The cost of this choice is real. A project whose dependencies are tracked as links to other git repositories needs network access at build time, needs a specific tool to be installed, and makes an offline or reproducible build harder to arrange than a plain submodule or a package manager would. The benefit is that the dependency versions are pinned in a file in the repository rather than resolved at build time, and that the same mechanism works across seven toolchains. For a library like this, where a mismatched dependency would change behaviour under load, that trade is arguable, and the README does not discuss it further.

The ITCH handler benchmark and the machine behind it

The README publishes micro-benchmarks for each component, and the first one is the ITCH handler, which measures how fast it can parse and handle ITCH messages from the input stream. The sample file is a NASDAQ ITCH 50 file, dated 01302017, downloadable from emi.nasdaq.com, and the program is fed the file on standard input.

The published run:

ITCH processing...Done!

Errors: 0

Processing time: 6.831 s
Total ITCH messages: 283238832
ITCH message latency: 24 ns
ITCH message throughput: 41460256 msg/s

The benchmark environment is stated in full, and it matters when you read those numbers. The machine is an Intel Core i7-4790K at 4.00 GHz with 8 logical cores and 4 physical cores, hyper-threading enabled, and 31.962 GiB of RAM with 21.623 GiB free. The operating system is Microsoft Windows 8 Enterprise Edition build 9200, 64-bit, with a 64-bit release build of the process.

So the headline figure of roughly 41 million messages per second comes from a 2014 desktop CPU running a 2017 feed on an operating system that reached end of life years ago, and it is a parse throughput on a captured file rather than a live-feed number. It is a reproducible starting point, not a forecast for your hardware.

The market manager: 309 nanoseconds per message

The market manager is the order book processor, and the benchmark measures how fast it can handle order operations, which the README lists as add, reduce, modify, delete and execute, while building an order book. The same ITCH file is used.

The published run reports a processing time of 1:27.616 m for 283238832 ITCH messages, a message latency of 309 ns and a message throughput of 3232727 msg/s. Underneath, 631217516 market updates were produced at 138 ns each, and the run ended with market statistics of 8371 symbols, 8371 order books, a maximum of 2422 order book levels, 2975 orders in a book and 1647972 total orders. The operation counters show 152865456 add order operations, 7037619 update operations, 152865456 delete operations and 5663712 execute operations.

The gap between the two benchmarks is the interesting part. Parsing the feed is roughly thirteen times cheaper per message than applying the resulting updates to the book, which is exactly what you would expect and exactly the number that tells you where the optimisation effort belongs in a system built on these parts.

The optimized market manager trades generality for speed

The README documents an optimized version of the market manager, and it lists the tricks, which is more useful than a single faster number. Symbols and order books live in fixed size pre-allocated arrays. Orders are stored in a pre-allocated array instead of a hash map, giving O(1) for every order operation with no overhead for get, insert, update and delete. The linked list of orders per price level is not maintained, only the order count. Price levels are stored in sorted arrays rather than red-black trees, and the sort order keeps the best prices at the end of the array, which gives good CPU cache locality and near O(1) search for orders close to the market price, but with a penalty for orders far from it. Price levels are drawn from a pool built on a pre-allocated array with O(1) create and delete.

The published run for that version shows processing time of 34.150 s and a message latency of 120 ns for the same 283238832 messages, and the output shown in the README is cut off after the throughput line.

The trade-off is written into the implementation notes rather than hidden. Keeping the best prices at the end of the array means the hot path is cache friendly, and an order that is far from the market pays for it. A book that is mostly far-from-market orders gets less from this design than the benchmark suggests, because the benchmark is a 2017 replay of a specific market.

Where CppTrader is the wrong tool

The first wrong-tool case is a production trading system. The components are performant and well documented, but the repository has no exchange connectivity beyond the ITCH handler, no order gateway, no risk engine, no persistence layer, no recovery procedure and no operational tooling. A trading platform is a system around these parts, and most of that system is not here.

The second is a team that wants to avoid owning a matching engine. Many venues and brokers expose an order management API, and using it moves the matching problem, the risk checks and the connectivity to somebody else. Rebuilding a matching engine in-house is a decision about a business-critical system, and adopting a component library does not make that decision reversible.

The third is a project with strict build reproducibility requirements. The gil-based dependency setup needs a network fetch and an extra tool, and the published benchmarks are tied to one dated machine and one dated feed file, so a team that must demonstrate performance on its own hardware will have to run the harness itself, using the sample file from emi.nasdaq.com.

MIT licence, 1.0.6.0, and a build system that is still moving

The project is licensed MIT, with the LICENSE file at the repository root, which is a permissive grant with no copyleft obligation and no network use clause. For a component library intended to be embedded in a commercial trading system, that is the licence most teams want, and the README links it directly from the badge at the top.

The release list shows 1.0.6.0 on 2026-02-27, described as fixed compilation errors, 1.0.5.0 in April 2025 as minor updates, and 1.0.4.0 in September 2023 as minor build updates. The last push was on 2026-09-09. The version is still in the 1.0.x line, and the recent release names are about builds rather than behaviour, which for a performance library is the reassuring kind of change, since it suggests the data structures and the matching semantics have been stable for a while.

The trade-off of a 1.0.x line with infrequent releases is that compatibility is informal. There is no deprecation policy in the README, and the API reference is generated with Doxygen, so the header files in include/ are the authoritative contract. A team pinning a version should expect to read those headers rather than a changelog, and should track the repository rather than a release tag if they want the compilation fixes.

Editorial conclusion

Adopt CppTrader if you are writing a market data or matching engine and want a tested order book, an ITCH parser and a benchmark harness to measure against, and use the optimized market manager only if your orders cluster near the top of book and you have measured the difference. Do not adopt it as a complete trading platform, since it ships no connectivity beyond the ITCH handler, no risk system and no persistence, and do not read the published benchmark numbers as your own, because they were measured on an older Windows 8 machine with a 2017 ITCH file. Before you build, clone with gil update so the submodules are present, and check the ITCH sample from emi.nasdaq.com so you can reproduce the published figures on your own hardware.

Frequently asked questions

Official sources

1. chronoxor/CppTrader on GitHub
2. Issues
3. License: MIT
4. README
5. Releases