Benchmarks

Feeding a live robot is the job of a separate, standalone shared library, libtse_connection, with its own C surface and its own ABI version. It is a deliberately small client stack: one handle, one message type and six protocols — http, https, ws, wss, udp and udp_multicast. What follows is a full request-and-reply round trip through that library, measured against the kernel's own loopback ceiling and against four external stacks: boost::beast, Python requests, websocket-client and the Python standard-library socket.

Reference machine: 8-core Apple Silicon, 127.0.0.1 loopback, one process. Slice: threads=1, keepAlive=1 for TCP and 0 for UDP, receiveMode=park, best-of-3 at a 1-minute load of 1.09.

How to read the tables

• Share(thrpt) is throughput divided by the ceiling throughput for that payload; Share(lat) is the ceiling latency for that payload divided by the measured round trip. Both are fractions of the kernel floor, higher is closer to the ceiling, and this is the headline metric — not the absolute MiB/s.
• latency RT is the measured round-trip mean. server_cost is the peer's own self-instrumented per-op time. lat w/o server is the first minus the second.
• throughput is the measured rate in MiB/s, base-1024. exp. thrpt w/o server is payload divided by lat w/o server: a single request in flight, no pipelining.
• raw drives the connection core directly, export-C is the shipped C ABI, export-C++ is the C++ facade over it, export-Python is the Python module over the shared library. raw, export-C and export-C++ drive the same in-process echo peer, so they differ only by the marshalling layer.
• boost, py-requests, py-websocket-client and py-socket(stdlib) are external stacks included for context; they are not part of the library. boost runs its own in-process Beast peer. The three Python clients drive the same pure-Python echo peer as export-Python, so those four rows differ only by the client stack.
• Unit convention: 1 GiB/s = 8 × 2^30 / 10^9 ≈ 8.59 Gbit/s. Do not read a GiB/s figure as Gbit/s.

What these numbers are not

• Everything here runs over the 127.0.0.1 loopback inside one process. There is no NIC and no physical link. Loopback throughput is bounded by memcpy, socket buffers and scheduling, not by any line rate, so a GiB/s figure on this page is not a Gbit/s network figure and a 10GbE expectation does not apply.
• Because there is no line rate to measure against, the right question is what fraction of the kernel loopback ceiling each layer reaches. That is the Share of ceiling column, and it is the number to read first.
• 1 MiB throughput over HTTP is load- and peer-scheduling sensitive: the round trip includes the peer's own two 1 MiB string copies, whose wall time swings with scheduling. Read it as an order of magnitude, not a measurement. The load-stable signals in this epoch are bulk TLS (HTTPS at 1 MiB, identical to the previous baseline at 157 MiB/s), WS and WSS at 128 KiB, and the small-payload cells.
• server_cost is the peer's own self-instrumented per-op time, from request fully received to response send starting. It deliberately excludes transport, TLS encryption and the HTTP or WebSocket handshake — which is why HTTPS server_cost is close to HTTP, and UDP server_cost is close to zero.
• The ceiling probe is one-way, a 1-byte trigger answered by an N-byte reply, while every other row is a round trip. Share(lat) is therefore a fraction-of-floor indicator, not a ratio of two identical operations.
• Third-party versions measured: requests 2.34.2, websocket-client 1.9.0, and the standard-library socket module. boost is boost::beast plus boost::asio over OpenSSL, a synchronous Beast client, running against its own in-process Beast peer.
• Python WS and WSS at 128 KiB do not appear at all: the report omits them as peer-limited rather than reporting a number that measures the peer.

Loopback baseline — kernel ceiling, no library

The kernel floor with no library in the path: a one-way 1-byte-trigger to N-byte-reply probe over 127.0.0.1. Every Share(thrpt) and Share(lat) figure in the tables below is a fraction of this row for the same payload.

Payload 64 B

A full round trip at 64 B for every protocol and every implementation. The report reads the small-payload cells as part of the stable signal for this epoch.

Payload 1024 B

The source table carries UDP only at this payload, so UDP only is published here. Rows absent from the report are absent from this page.

Payload 131072 B

128 KiB, one of the load-stable signals. The Python WS and WSS rows are omitted by the report itself because they are peer-limited: the pure-Python echo peer's transport dominates at this size, so those runs measure the peer rather than the client and are not comparable to the C-peer and boost-peer rows.

Payload 1048576 B

1 MiB. The HTTP rows are the least precise cells on this page: the round trip includes the peer's own two 1 MiB string copies, whose wall time swings with machine load and scheduling, so a cross-report comparison of them reads as a regression that is not there. The HTTPS rows, by contrast, are load-stable and reproduced the previous baseline exactly at 157 MiB/s.

Source: connection — re-measure and regression analysis, 2026-08-08, section Q2 (redone measurement), best-of-3 at a 1-minute load of 1.09. Column definitions and caveats: the connection benchmark methodology document.