Six flavors. Results with context.

Updated · 3 October 2026

Latest tests. Per-language CDFs.

The converted-values-v2 codec campaign admits 25 adapters, 320 isolated field-work probes and 554 operation rows. The full-session roster also includes the latest correctness, wire and scheduling-delay tests; a functional pass is not promoted into a latency distribution.

The transport and capacity tables below are retained September campaigns, not newly collected October timings.

Retained reference · 20 September 2026

A comparison with the variables held still.

The client sends a varied FIX NewOrderSingle and completes the sample only after receiving, parsing and extracting the required fields from the derived ExecutionReport. The schedule is open-loop: response time starts at the intended send slot, so scheduler delay is charged rather than hidden.

Swipe the diagram horizontally, or open it at full size.

Understand all four session scenarios → · Codec microbenchmark operation diagrams →

At a glance

Lowest measured p50 for each flavor.

The selected row is the lowest p50 within each flavor. Compare complete per-flavor tables below when tail latency or deployment constraints matter.

Capacity sweep

Passing rates stop where saturation starts.

A separate SCAN campaign stepped the shared kernel-TCP, single-session harness through 50k, 75k and 100k requests/s. The table publishes each flavor’s highest passing target and first failed target; it does not turn an overload point into a sustained result.

Diagnostic SCAN run dated 29 September 2026, source revision 1bec04aa3. BrokerForge housekeeping processes occupied other cores. Read the complete contract and retained saturation evidence →

Workload and measurement points

What does each test measure?

Expand a scenario to follow the FIX messages, locate t0/t1, and inspect a complete captured example for every leg. The shaded interval is timed; grey dashed work is excluded. These diagrams explain the tests, not their performance.

Swipe diagrams horizontally on a small screen, or open them at full size.

What this test measures: Order → acknowledgementnos_er · D → 8 · Client clock

Client clock: t1 − t0. Both timestamps belong to one endpoint; synchronized host clocks are not required.

t0 · start

Published transport reference: the intended send slot, before any scheduling delay. Canonical actual-start tests: immediately before order construction and the engine-specific send call.

t1 · stop

After the client parses the derived acknowledgement and completes the required business-field extraction and checks.

Included

Client order construction/send, both endpoints, the network, server order processing and acknowledgement construction, then client reply processing. The displayed open-loop reference also includes scheduler delay.

Excluded

Session establishment and warm-up are outside the headline samples. An acknowledgement is not a trade fill.

Compare the canonical actual-start boundary

Canonical nos_er starts immediately before construction/send, not at the intended schedule slot. Scheduling delay is a separate probe. Do not mix that service-time distribution with the displayed open-loop reference.

Captured sample FIX messages

One complete, correlated chain from the synthetic QuickFIX/C++ functional audit. These are actual captured bytes illustrating the current canonical wire shape, not messages from the older transport campaign or measured latency samples.

The acknowledgement echoes order 11=1, symbol LCOM1, buy side, quantity 1000 and price 10000.00000. ExecType 150=0 and OrdStatus 39=0 mean New: CumQty is 0, LeavesQty is 1000 and AvgPx is 0. No LastQty/LastPx fill fields are present.

1. CLIENT → SERVER · NewOrderSingle 35=D

8=FIX.4.4|9=132|35=D|34=2|49=CLIENT|52=20261003-00:42:20.433|56=SERVER|
11=1|21=1|38=1000|40=2|44=10000.00000|54=1|55=LCOM1|60=20260703-12:00:00.000|
10=201|

2. SERVER → CLIENT · ExecutionReport · New acknowledgement 35=8

8=FIX.4.4|9=182|35=8|34=2|49=SERVER|52=20261003-00:42:20.433|56=CLIENT|
6=0.00000|11=1|14=0|17=TCP-EXEC|37=TCP-ORDER|38=1000|39=0|44=10000.00000|54=1|55=LCOM1|60=20260703-12:00:00.000|150=0|151=1000|
10=060|

| represents SOH (ASCII 0x01). Remove display line breaks and restore SOH to recover the exact message, including valid BodyLength (9) and CheckSum (10). FIX SendingTime (52) is a wall-clock field, not the monotonic measurement clock: do not subtract these timestamps to estimate latency. Tag 60 retains the fixed July fixture time.

Download the original synthetic wire capture → · Download all checked examples and source hashes →

What this test measures: Market-data request → full bookmd · V → W · Client clock

Client clock: t1 − t0. Both timestamps belong to one endpoint; synchronized host clocks are not required.

t0 · start

Immediately before constructing and sending the market-data request, at actual task start.

t1 · stop

After the client parses the full snapshot and completes the required book-field extraction and checks.

Included

Request construction/send, server request parsing and book construction, both network legs, and client parsing/checking of the ten-level snapshot.

Excluded

Session establishment and warm-up. No order submission or ExecutionReport leg belongs to this test.

This diagram explains the canonical actual-start test. It does not assert that a matching passing distribution is available for the current chart selection.

Captured sample FIX messages

One complete, correlated chain from the synthetic QuickFIX/C++ functional audit. These are actual captured bytes illustrating the current canonical wire shape, not messages from the older transport campaign or measured latency samples.

Request 262=1 asks for 264=10 levels and both bid/offer types. Its snapshot echoes the request ID and symbol; 268=20 counts twenty entries, not twenty levels. The complete wire example includes all ten bid/offer pairs in order.

1. CLIENT → SERVER · MarketDataRequest 35=V

8=FIX.4.4|9=113|35=V|34=2|49=CLIENT|52=20261003-00:42:26.939|56=SERVER|
146=1|55=LCOM1|262=1|263=0|264=10|265=0|267=2|269=0|269=1|
10=083|

2. SERVER → CLIENT · MarketDataSnapshotFullRefresh 35=W

8=FIX.4.4|9=688|35=W|34=2|49=SERVER|52=20261003-00:42:26.939|56=CLIENT|
55=LCOM1|262=1|268=20|
269=0|270=10000.00000|271=1000|269=1|270=10001.00000|271=1000|
269=0|270=9999.99000|271=1010|269=1|270=10001.01000|271=1010|
269=0|270=9999.98000|271=1020|269=1|270=10001.02000|271=1020|
269=0|270=9999.97000|271=1030|269=1|270=10001.03000|271=1030|
269=0|270=9999.96000|271=1040|269=1|270=10001.04000|271=1040|
269=0|270=9999.95000|271=1050|269=1|270=10001.05000|271=1050|
269=0|270=9999.94000|271=1060|269=1|270=10001.06000|271=1060|
269=0|270=9999.93000|271=1070|269=1|270=10001.07000|271=1070|
269=0|270=9999.92000|271=1080|269=1|270=10001.08000|271=1080|
269=0|270=9999.91000|271=1090|269=1|270=10001.09000|271=1090|
10=218|

| represents SOH (ASCII 0x01). Remove display line breaks and restore SOH to recover the exact message, including valid BodyLength (9) and CheckSum (10). FIX SendingTime (52) is a wall-clock field, not the monotonic measurement clock: do not subtract these timestamps to estimate latency. Tag 60 retains the fixed July fixture time.

Download the original synthetic wire capture → · Download all checked examples and source hashes →

What this test measures: Book → derived order → acknowledgementmd_nos_er · V → W → D → 8 · Client clock

Client clock: t1 − t0. Both timestamps belong to one endpoint; synchronized host clocks are not required.

t0 · start

Immediately before constructing and sending the market-data request, at actual task start.

t1 · stop

After parsing the final acknowledgement and completing the required report checks.

Included

Both request/reply legs, full-book parsing/checks, client-side order derivation from the received book, order construction/send and final acknowledgement processing. One interval covers the entire chain.

Excluded

Session establishment and warm-up. A prebuilt constant reaction order is not a valid substitute for deriving it from the parsed snapshot.

This diagram explains the canonical actual-start test. It does not assert that a matching passing distribution is available for the current chart selection.

Captured sample FIX messages

One complete, correlated chain from the synthetic QuickFIX/C++ functional audit. These are actual captured bytes illustrating the current canonical wire shape, not messages from the older transport campaign or measured latency samples.

The received marker 262=1 is odd, so the client derives a buy (54=1). It uses the parsed best ask 10001.00000 for 44 and the ask size 1000 for 38 (within the lot/cap bounds). Order 11=1 carries the same marker; the final acknowledgement echoes these derived values.

1. CLIENT → SERVER · MarketDataRequest 35=V

8=FIX.4.4|9=113|35=V|34=2|49=CLIENT|52=20261003-00:42:35.638|56=SERVER|
146=1|55=LCOM1|262=1|263=0|264=10|265=0|267=2|269=0|269=1|
10=079|

2. SERVER → CLIENT · MarketDataSnapshotFullRefresh 35=W

8=FIX.4.4|9=688|35=W|34=2|49=SERVER|52=20261003-00:42:35.638|56=CLIENT|
55=LCOM1|262=1|268=20|
269=0|270=10000.00000|271=1000|269=1|270=10001.00000|271=1000|
269=0|270=9999.99000|271=1010|269=1|270=10001.01000|271=1010|
269=0|270=9999.98000|271=1020|269=1|270=10001.02000|271=1020|
269=0|270=9999.97000|271=1030|269=1|270=10001.03000|271=1030|
269=0|270=9999.96000|271=1040|269=1|270=10001.04000|271=1040|
269=0|270=9999.95000|271=1050|269=1|270=10001.05000|271=1050|
269=0|270=9999.94000|271=1060|269=1|270=10001.06000|271=1060|
269=0|270=9999.93000|271=1070|269=1|270=10001.07000|271=1070|
269=0|270=9999.92000|271=1080|269=1|270=10001.08000|271=1080|
269=0|270=9999.91000|271=1090|269=1|270=10001.09000|271=1090|
10=214|

3. CLIENT → SERVER · NewOrderSingle 35=D

8=FIX.4.4|9=132|35=D|34=3|49=CLIENT|52=20261003-00:42:35.638|56=SERVER|
11=1|21=1|38=1000|40=2|44=10001.00000|54=1|55=LCOM1|60=20260703-12:00:00.000|
10=216|

4. SERVER → CLIENT · ExecutionReport · New acknowledgement 35=8

8=FIX.4.4|9=182|35=8|34=3|49=SERVER|52=20261003-00:42:35.638|56=CLIENT|
6=0.00000|11=1|14=0|17=TCP-EXEC|37=TCP-ORDER|38=1000|39=0|44=10001.00000|54=1|55=LCOM1|60=20260703-12:00:00.000|150=0|151=1000|
10=075|

| represents SOH (ASCII 0x01). Remove display line breaks and restore SOH to recover the exact message, including valid BodyLength (9) and CheckSum (10). FIX SendingTime (52) is a wall-clock field, not the monotonic measurement clock: do not subtract these timestamps to estimate latency. Tag 60 retains the fixed July fixture time.

Download the original synthetic wire capture → · Download all checked examples and source hashes →

What this test measures: Completed tick → reaction-order arrivaltick_to_trade · W → D · Feed/server clock

Feed/server clock: t1 − t0. Both timestamps belong to one endpoint; synchronized host clocks are not required.

t0 · start

Immediately before sending the completed top-of-book tick. Constructing and finalising W happens before this timestamp.

t1 · stop

The first instruction of the feed-side application callback after the engine frames/parses the returning order, before benchmark-side marker/extraction checks.

Included

Tick send, both network legs, client tick parsing, decision and order derivation/construction/send, and feed-side engine delivery of the returning order.

Excluded

Tick construction and finalisation, then post-t1 marker matching and benchmark extraction checks. Those checks can still invalidate the result. There is no acknowledgement/fill leg.

This diagram explains the canonical actual-start test. It does not assert that a matching passing distribution is available for the current chart selection.

Captured sample FIX messages

One complete, correlated chain from the synthetic QuickFIX/C++ functional audit. These are actual captured bytes illustrating the current canonical wire shape, not messages from the older transport campaign or measured latency samples.

The tick is top-of-book only: 268=2, one bid and one offer. Marker 262=1 produces buy order 11=1 at the parsed ask 10001.00000 for quantity 1000. No 35=8 is sent in the headline tick-to-trade workflow.

1. SERVER → CLIENT · MarketDataSnapshotFullRefresh 35=W

8=FIX.4.4|9=138|35=W|34=2|49=SERVER|52=20261003-00:42:39.983|56=CLIENT|
55=LCOM1|262=1|268=2|
269=0|270=10000.00000|271=1000|269=1|270=10001.00000|271=1000|
10=005|

2. CLIENT → SERVER · NewOrderSingle 35=D

8=FIX.4.4|9=132|35=D|34=2|49=CLIENT|52=20261003-00:42:39.984|56=SERVER|
11=1|21=1|38=1000|40=2|44=10001.00000|54=1|55=LCOM1|60=20260703-12:00:00.000|
10=223|

| represents SOH (ASCII 0x01). Remove display line breaks and restore SOH to recover the exact message, including valid BodyLength (9) and CheckSum (10). FIX SendingTime (52) is a wall-clock field, not the monotonic measurement clock: do not subtract these timestamps to estimate latency. Tag 60 retains the fixed July fixture time.

Download the original synthetic wire capture → · Download all checked examples and source hashes →

Read the complete canonical scenario contract → · Codec operation diagrams and all nine microbenchmark tests →

Detailed reports

Open the evidence for one deployment model.

Each flavor report combines its transport percentile profile, same-language codec microbenchmarks, the full pinned open-source comparison roster, and available rate/capacity evidence.

Browse every target and its current four-flow status → The complete per-language inventory includes not-run, non-parity and excluded rows. Browse every committed benchmark file →

Flavor 1 of 6

C++

The native reference engine exposes every measured path, from ordinary kernel TCP through both vendor user-space TCP APIs.

Flavor 2 of 6

Java Pure

The independent JVM engine stays entirely in Java. Onload and VMA accelerate its ordinary sockets by interposition without introducing JNI into the engine path.

Flavor 3 of 6

Java/JNI

The Java API over the native C++ core combines JVM integration with access to native vendor transports.

Flavor 4 of 6

.NET Pure

The independent C# engine remains managed end to end. Onload and VMA operate underneath its socket API while the FIX engine stays native-library free.

Flavor 5 of 6

.NET Native

The C# API over the native C++ core provides the complete measured native transport set through the managed boundary.

Flavor 6 of 6

Rust

The independent Rust engine implements the same benchmark workflow directly and exposes all five measured network paths.

What this proves

Comparable latency, not every production question.

This campaign compares the single-session response path at a fixed offer. It does not claim maximum throughput, production topology latency or equivalent resource cost. Multi-session mono, pool and shard results are collected separately because concurrency changes the scheduling and ownership model.