Native speed, flat tails

HTTP

The fastest web server in the world

A web server on the built-in HTTP stack, compiled to a single native binary and load-tested over loopback. The server is pinned to one core, the load generator to another. It serves faster than wrk can issue requests.

class HelloHandler implements HttpRequestHandler {
  private final ByteArray response;
  HelloHandler() {
    String body = "Hello from SuperJ!\n";
    this.response = new ByteArray(
      "HTTP/1.1 200 OK\r\nContent-Length: "
      + body.length() + "\r\n\r\n" + body);
  }
  public void handle(HttpRequest r, SessionWriter w) {
    this.response.rewind();  // reuse — zero alloc
    w.write(this.response);
  }
}

• aot

  No JIT warm-up

  Compiled through LLVM to native code. Full speed from request one — no profiling, no deoptimization.

• no gc

  No pauses

  Arena memory is reclaimed deterministically. That's why the latency curve stays flat under load.

• zero-alloc

  Allocation-free hot path

  The response buffer is built once and rewound per request. Steady-state serving allocates nothing.

• one loop

  No lock traffic

  One event loop, one thread — no locks, no context switches, no cross-core cache traffic on the hot path.

superj_web

The edge server — 1.85× faster than nginx, up to 4.8× faster than Caddy

The same stack, wrapped in a full edge web server with TLS termination, routing, a static file cache, and reverse proxy. Despite the added overhead it beats nginx and Caddy on the same box, on every file size, for both static serving and reverse proxy.

Static file serving — superj_web vs nginx vs Caddy

Ryzen 9 9950X3D · server on one core, wrk on another · loopback TCP · 3-run average. Caddy v2.8.4, superj_web built with --release --enterprise. nginx: 1.24.0, single worker, sendfile on, access_log off.

Reverse proxy — superj_web vs Caddy (front → back, isolated CPUs)

100 keep-alive conns · front on CPU 14, back on CPU 15 · 128 pooled keep-alive conns per upstream · raw response forwarding (no rebuild).

Why it wins. The static hot path is allocation-free: pre-built responses, rewind() reuse, an in-memory file cache with lazy mtime invalidation. The proxy hot path adds connection pooling (128 keep-alive conns per upstream) and raw response forwarding with prepareForReuse() on the reader — no per-request allocations on either path. The single-threaded event loop handles 288K req/s (static 128B) and 107K req/s (proxy 128B) on one core; the gaps to nginx/Caddy are algorithmic, not threading.

SEDA

Cross-process coordination — 88 ns/round

The SEDA sequencer is the total-order event stream that replaces shared mutable state. In-process on an M4 Max it measured 88 ns/round — faster than raw cross-process mmap spin (152 ns/round), because it never crosses cores and pays no cache-coherence tax.

Application — xpe_db

A real database, not just kernels

xpe_db is an embedded document database with an HNSW vector index, an inverted index, a hash index, and a JWT/auth subsystem — ported from Java to SuperJ. The binary runs with no JVM, no GC, no JIT warm-up. These are application-level numbers, the kind a user actually feels.

HNSW vector index — SuperJ vs C++ hnswlib

Byte-quantized (uint8) L2 distance, M=16, maxM0=32, ef=200, k=10, dims=128, n=1000. Same seeded RNG, same workload. Precise 20K-query nanoTime bench.

Inverted & hash indexers — SuperJ vs Java

SuperJ: enterprise SDK, -O3 (bounds check on, no SIMD). Java: JDK 17, cold JIT. macOS arm64.

JWT / auth — SuperJ vs Java

Case study — superK

superK vs kdb+ — 13 of 14 wins, up to 84×

superK is a time-series database built from the ground up in SuperJ — fully compatible with the q language and the q-IPC wire protocol: a q client that connects to kdb+ connects to superK without modification, and a q script that runs on kdb+ runs on superK. Same query language, same data model, same client protocol. No JVM, no JIT, no garbage collector; single-threaded by design, scaled with processes, not threads.

The benchmark. The paper "Benchmarking Specialized Databases for High-frequency Data" (arXiv:2301.12561) defines 14 query benchmarks over cryptocurrency exchange data — trades and order book — covering volume aggregation, VWAP, market depth, bid-ask spread, NBBO, log returns, and volatility. It was designed to compare kdb+ against ClickHouse, InfluxDB, and TimescaleDB. kdb+ won. We use the same 14 benchmarks, the same data shape, the same queries — both engines on the same machine, same core, same data, timed the same way. paper_verify.q proves the two databases agree value by value before any timing is quoted; both engines run the same q text through their own REPL, so the clock covers the full path a user hits (parse, evaluate, format, print), not just an isolated kernel.

AMD Ryzen 9 9950X3D · 30 GB RAM · NVMe · both engines taskset -c 2 (isolated core), warm cache · 10 iterations, mean · data: 30 partitions + 1 NBBO day, ~20M trades rows, ~33M order_book rows, 39 GB, 3 symbols / 2 sides / 5 exchanges · superK commit 2c84085, superj build --release (AVX2, no bounds check, -O3) · kdb+ 5.0

superK wins 13 of 14. The one remaining loss — T-V2 at 1.02× — is within measurement noise; the two engines are effectively tied. The wins range from 1.04× (C-R) to 84× (O-T). The win comes from the storage and query engine itself, not a different data shape: superK implements the same splayed, parted, p#-indexed columnar model as kdb+, AOT-compiled through LLVM with zero allocation on the hot path.

The ledger

SuperJ vs C — the full picture

We ran 54 head-to-head benchmarks against C (and where relevant, C++ simdjson/hnswlib, Rust, Java) on the same machine, the same workload, the same iteration count. Each bar below splits at the speed ratio: amber is SuperJ, blue is C. A 50/50 split is a tie; if SuperJ is 2× faster, its segment is twice as long. We show every benchmark, including the ones we lose.

How the bars are calculated. Each benchmark pits SuperJ against C (or C++ simdjson / C++ hnswlib / Rust, where noted) on the same machine, the same workload, the same iteration count. SuperJ is compiled with clang -O3 linking; C with clang -O3 (g++ -O3 -mcpu=native for the C++ benchmarks). Best-of-3 warm runs. The split point of each bar is the speed ratio: if SuperJ is r× the time of C, SuperJ's segment is 1/(1+r) and C's is r/(1+r) — so a 2× win gives SuperJ a 2:1 segment, a tie is 50/50, and a loss shrinks SuperJ's segment. A win is >5% faster, a tie is within ±5%, a loss is >5% slower. No benchmark is cherry-picked — the 54 suites cover arithmetic, array scans, string ops, object alloc/access, method dispatch, networking, integer parsing, hash maps (Object keys, 3 key distributions), SHA-256, BitSet, JSON (4 document sizes), wide-integer arithmetic (i128/i256/i512), secp256k1 ECDSA, 8 Benchmarksgame ports, Base64, Brainfuck, SIMD matrix multiply, and a full HNSW vector index. The complete result table and methodology live in benchmarks/RESULTS.md and doc/hnsw_performance.md in the source tree.

Where SuperJ wins

• compute

  Hash maps

  Plain-object puts/gets at parity with C; up to 7× faster than tidwall C on adversarial keys; 4× faster on scattered int keys.

• numerics

  Wide-integer division & SIMD matmul

  i256/i512 general division 3-10× faster than C; cache-blocked SIMD-tile GEMM beats auto-vectorized C by 1.15-2.57× at every matrix size.

• application

  vs Java

  3.4-11.7× faster on indexers and JWT — zero allocation on the hot path, native crypto intrinsics, no GC.

Where C still wins

• gap

  String concat & valueOf

  1.25-1.63× slower on allocation-bound paths — SuperJ allocates a real heap String; C writes a throwaway stack buffer. charAt is at parity.

• gap

  Base64 decode

  1.10× slower — per-element pointer reload + bounds checks on a stride-3/4 pattern. Encode is now at parity after #2376. --no-bounds-check closes most of the remaining gap.

• gap

  JSON object (77B) vs simdjson

  1.13× slower — the per-byte scalar tail on docs under 64B. SuperJ is faster than simdjson on 7B and 22B docs, and within 9% on 5.7KB.

• gap

  Bounds-checked random access

  BitSet scan, object field access, reverse-complement — the per-access checks C doesn't carry. --no-bounds-check closes most of it.

Reproduce

Run the benchmarks yourself

The HTTP server and load generator ship with SuperJ at demo/sj/demo/WebServer.sj and demo/sj/demo/WebClient.sj. The edge server benchmark script is in the superj_web repo.

# HTTP server + wrk
superj compile "$SJ_HOME/demo/sj/demo/WebServer.sj" --sdk-path "$SJ_HOME/sdk" --link --output webserver
./webserver 8080 &
wrk -t2 -c100 -d30s --latency http://127.0.0.1:8080/

# pipelined client (when wrk is the bottleneck)
superj compile "$SJ_HOME/demo/sj/demo/WebClient.sj" --sdk-path "$SJ_HOME/sdk" --link --output webclient
./webclient 8080 64 16 15

# scale across cores — same binary, more copies
for i in 1 2 3 4; do ./webserver 8080 & done