Performance

One sender, one receiver, each in a process of its own: messages per second one way, and the round trip when the receiver answers each message at once. A sender writes each message from its own buffer, and the receiver ends with it in its own; libraries that lend out shared memory have the receiver copy the message out of it.

One publisher process and 1 or 4 subscriber processes; every subscriber receives every message. Lossless: a subscriber that falls behind holds the publisher back. Lossy: it loses messages instead, and the publisher never waits. The rate is the slowest subscriber's; a lossy library's figure counts the messages that arrived, and the share lost is beside it.

Producer and consumer processes, each message to exactly one consumer: 1 producer and 1 consumer, and 4 of each. The rate is every consumer's messages together.

Client and server processes; each client sends a request, waits for its reply, and sends the next. 1 client and 1 server, 4 clients and 1 server, and 4 of each, where the servers share the requests. The rate is every client's calls together; a call's p50 is its round trip.

Aeron in detail

Everything above sends and receives one message per call, with every library. FastIPC and Aeron also have calls that move several messages at once, so here the two of them run with both ends batching, in the same run, each in its configuration from above. FastIPC's sender calls fipc_send_many with 16 messages, and its receiver fipc_recv_many with room for 16: it waits for the first message, then takes every further one already there, up to 16. Aeron's sender offers 16 messages as one block (aeron_exclusive_publication_offer_block), and its receiver polls with a fragment limit of 16. FastIPC counts the faster of a waiting and a polling receive, as above; Aeron always polls. A round trip has one message at a time to send, so it isn't here. Each cell is FastIPC's figure and how it compares with Aeron's; the last rows batch 64 messages at both ends, and hovering a cell shows both configurations. Batch both ends: a batching sender whose receiver takes one message per call runs slower than one that sends one message per call, as the receiver falls behind and the ring stays full.

Who is faster with batches of 16 at both ends: in the 16-byte stream FastIPC on Linux x86-64 (by 19%) and Linux ARM64 (by 14%), Aeron on Windows (by 7%) and macOS (by 2%); in the 1 KiB stream FastIPC on Linux x86-64 (by 49%), Windows (by 29%), macOS (by 168%) and Linux ARM64 (by 128%); in the lossless 16-byte broadcast to 1 subscriber FastIPC on Linux x86-64 (by 11%) and Linux ARM64 (by 19%), Aeron on Windows (by 2%), the two level on macOS; in the lossless 16-byte broadcast to 4 subscribers FastIPC on Linux x86-64 (by 4%), Windows (by 9%), macOS (by 4%) and Linux ARM64 (by 35%).

Which of the four patterns each library has, and how its messages travel. A pattern a library lacks shows as a dash in the results: the harness doesn't build one out of something else (a work queue from a broadcast, say), because the library's users couldn't either.

iceoryx2 also has events and a blackboard, Aeron an archive and a cluster, and ZeroMQ and NNG more socket patterns; this page compares the four patterns FastIPC has. Language bindings: FastIPC has C, C++, Zig, Python, C#, Java, Rust, Lua, JavaScript and Go; this comparison calls every library from C++, and iceoryx2 from Rust, its own language.

Streams and round trips

Broadcasts

Work queues

Services

Buffers

Each library's buffer per pattern; for FastIPC and Aeron, the shared memory it maps in the charted case (a stream, a broadcast to four subscribers, a work queue and a service of 4 × 4). The other libraries' sizes are bytes of messages: at 16 B, 64 KiB is 4096 messages. Under it, Aeron's conductor and fragment limit on each platform.

Aeron's media driver conductor, which moves a publisher's flow-control limit: Linux x86-64, macOS, Linux ARM64: backs off into sleeps when idle (Aeron's default); Windows: spins.

The most messages one of Aeron's subscription polls took (its fragment limit; a message up to its MTU is one fragment): 1 (stream), 1 (broadcast).

Machines

The Linux x86-64 and Windows columns ran on one ASUS Zenbook 14 laptop on AC power (Intel Core i9-13900H: 6 P-cores with Hyper-Threading and 8 E-cores, 32 GB), one after the other: Windows 11, then Ubuntu 24.04 in WSL2. A thread's wake-up is slow in WSL2 (about 50 µs), which costs most the libraries that hand each message between threads (ZeroMQ, NNG). The macOS and Linux ARM64 columns ran on a MacBook Air (Apple M1: 4 performance and 4 efficiency cores, 8 GB), one after the other: macOS 26.5, then Ubuntu 24.04 in a virtual machine (Lima on Apple's Virtualization framework, 4 vCPUs, 4 GB). On macOS a case with more spinning processes than the 4 performance cores runs some of them on the efficiency cores. The VM's four vCPUs leave out the cases of 4 producers and 4 consumers and of 4 clients and 4 servers, eight spinning processes each (a dash in its column), and its broadcast to four subscribers runs five spinning processes on them (Aeron's media driver, which backs off into sleeps when idle there, is a sixth).

• Linux x86-64: 13th Gen Intel(R) Core(TM) i9-13900H, Linux-6.18.54.1-microsoft-standard-WSL2-x86_64-with-glibc2.39; 3 runs of 1 s after 0.3 s of warm-up, 2026-10-25.
• Windows: 13th Gen Intel(R) Core(TM) i9-13900H, Windows-11-10.0.26200-SP0; 3 runs of 1 s after 0.3 s of warm-up, 2026-10-25.
• macOS: Apple M1, macOS-26.5.1-arm64-arm-64bit-Mach-O; 3 runs of 1 s after 0.3 s of warm-up, 2026-10-25.
• Linux ARM64: Apple M1, in a Lima VM (4 vCPUs, 4 GB), Linux-6.8.0-147-generic-aarch64-with-glibc2.39; 3 runs of 1 s after 0.3 s of warm-up, 2026-10-25.
• Versions: ZeroMQ 4.3.5, NNG 2.0.0, cpp-ipc 1.4.1, iceoryx2 0.10.0, Aeron 1.53.3, Boost.Interprocess 1.92.0; FastIPC 1.0.0. The harness and the C and C++ libraries are built by MSVC 17.13 on Windows, GCC 13.3 on Linux and Apple Clang 16 on macOS, iceoryx2 by Rust 1.99 and FastIPC by Zig 0.17.0.

What the cases above don't show, from FastIPC's own benchmark suite on the same machines: a receiver that sleeps, the lowest latency, messages longer than the ring, and setting up a connection.

What each language's binding costs: copied messages per second between two processes, and under each the bytes of message per second, through each language's own benchmark, on the same machines as the comparison. Short messages show the cost of each call into the library; at 64 KiB the copy itself dominates and most languages run close to C. Medians of 5 runs round-robin, release builds, 512 KiB rings; Linux x86-64 and Windows 2026-10-25, macOS and Linux ARM64 the same night, 2026-10-24 to 25; every size and the zero-copy calls are in bindings-baseline.md.

What is the fastest IPC library?

It depends on the pattern and the message. FastIPC is the fastest, or level with the fastest, in 28 of the 30 measurements of the case-by-case table; Aeron leads the other 2. Of the libraries here, only FastIPC has all four patterns (stream, broadcast, work queue and service) in shared memory. (Case by case.)

How does FastIPC compare with Aeron?

Aeron is the closest rival. FastIPC has the lower round-trip latency on Linux x86-64 and Windows, and the two are about even on macOS and Linux ARM64. FastIPC leads 16-byte one-way throughput on Windows, macOS and Linux ARM64, and Aeron leads on Linux x86-64 (by 12%). FastIPC leads it at 1 KiB on every platform here. Aeron also works across machines, over UDP. On one machine FastIPC is simpler to set up: Aeron needs a media driver running, as a process of its own or embedded in one of the applications. Either library can let an idle receiver sleep, but a sleeping Aeron receiver sees a new message only when its sleep ends, whereas FastIPC's sender wakes its receiver as soon as it sends. Aeron has no work queue or request-reply service. (Charts above; details in Aeron in detail.)

Is FastIPC faster than ZeroMQ?

Yes, in every one of the 72 measurements where both ran: a 16-byte round trip, for example, is 240 to 478 times as quick. ZeroMQ passes each message through a socket and its own I/O threads, while FastIPC writes it into memory both processes map. ZeroMQ also works across machines; FastIPC works within one.

How does FastIPC compare with iceoryx2?

Both are shared-memory libraries without a broker. FastIPC is faster in every one of the 68 measurements where both ran; its request-reply calls, for example, run 3.1 to 3.6 times as fast. iceoryx2 has no work queue and delivers each request to every server, so its servers don't share a load. It has events and a blackboard, and runs on more platforms (QNX, FreeBSD and others).

How does FastIPC compare with NNG (nanomsg)?

NNG passes each message through its own threads, and every hand-over between threads costs a wake-up, so it is far slower here: a 16-byte round trip is 195 to 1,077 times as quick with FastIPC. NNG works across machines; FastIPC works within one.

Is shared memory faster than a Unix domain socket?

Yes. Here a 16-byte round trip through FastIPC's shared memory is 11 to 20 times as quick as over a Unix domain socket. A socket costs a system call and a copy through the kernel for every send and receive; shared memory needs neither once the connection is set up.

Can I run these benchmarks myself?

Yes. bench/alternatives in the repository fetches and builds every library at the version shown and builds the harness with CMake, and run.py runs every case and writes the medians. The README there has the commands, and the method above says what each case does.