Benchmarks

Benchmarks published for Elide 1.6.0. Each number links to a terminal recording or downloadable raw measurement reports. JavaScript startup and HTTP serving were re-recorded on October 15 with the release build 1.6.0, without the optional Python component. Python results retain their October 2 recording. No JVM benchmark is published.

1. JavaScript hello-world startup, mean: Elide 1.43 ms, Bun 1.63 ms, Deno 6.31 ms, Node 11.70 ms.
2. Python hello-world startup, mean: Elide 4.8 ms, CPython 6.0 ms.
3. HTTP serving, requests per second: Elide 635,510, Deno 163,511, Bun 156,974, Node 123,519.

JavaScript startup

Time to run a one-line hello.js (console.log("Hello, World!");) and exit. Lower is better.

Python startup

Time to run a one-line hello.py (print("Hello, World!")) and exit. Lower is better.

Python needs the optional component (elide setup python); see Python with Elide.

HTTP serving

Requests per second and latency for a fetch handler that returns Hello, World!. Higher requests per second and lower latency are better.

// server.mjs
export default {
  port: 3000,
  hostname: "127.0.0.1",
  fetch() {
    return new Response("Hello, World!");
  },
};

The server CPU mask was 0-11,24-35; the client mask was 12-23,36-47: twelve physical cores and their SMT siblings per side, in a private network namespace. The table shows one recorded run on this machine.

Each server used its defaults and one JavaScript application context. Elide also uses transport threads. This is an apples-to-apples comparison of default settings with the same handler and load, not a comparison of maximum multi-core capacity. Node uses an equivalent native http handler with the same 13-byte body; HTTP headers remain runtime-specific. Its separate run used the same machine, CPU masks, private network namespace, warmup, and load settings, with no reported socket or HTTP status errors. Node’s raw report and handler are included in the reproduction package. The recording below covers the original three runtimes.

Multi-context peak serving

The same Elide binary reached 10,697,938 requests/s with 24 application contexts in one process and HTTP/1.1 pipeline depth 16. Three fresh-server runs measured 10,697,938, 10,376,454, 10,648,229 requests/s; the mean was 10,574,207 requests/s. Every warmup and measured run reported zero request errors. Ordered-response preflight checked status, framing, and body bytes before each load.

This is a separate tuned throughput experiment. It does not establish a speedup over the default-serving comparison above, an off-host capacity estimate, or a maximum for other runtimes. Pipeline latency measures batches; we do not publish it as individual-request latency.

Parallel runtime comparison

We also ran Bun 1.4.3, Deno 2.9.7, and Node.js 24.22.0 LTS against the peak workload above: same server/client CPU masks, 256 connections, sixteen client threads, pipeline depth 16, URL parsing, and nine-byte response. Each configuration had three fresh-server runs, each with 60 seconds warmup and 60 seconds measurement. Runtimes ran sequentially, with configurations interleaved between repeats. These results do not use estimated process scaling or memory penalties.

A fresh Elide control run reached 11,416,311 requests/s without errors. The comparison retains the previously published three-run peak instead of replacing it with this single control.

The competitor measurements were:

Node’s single-process measured runs reported 48, 42, and 49 timeout events respectively; their warmups reported 62, 52, and 64. All other measured runs and warmups reported zero connection, read, write, response-status, and timeout errors. Counts are wrk events, not failed-request rates.

Bun uses Linux port sharing; Deno uses worker isolates within one process; Node uses its built-in cluster coordinator. No external proxy is involved. Node uses its native http API; the other handlers use fetch-style APIs. All parse the URL and construct the response, but default HTTP headers differ. This is a comparison of these configurations, not a ceiling for any runtime. RSS savings were not benchmarked.

Download sources and raw results · Comparison summary

How contexts share a process

elide run --contexts=auto server.mjs

This enables automatic context sizing; --contexts=24 requests a fixed count. The entry module runs in each context. Contexts handle requests concurrently, keep JavaScript globals and module state separate, and share one managed heap and garbage collector. Eligible parsed and JIT-compiled code can be reused across contexts. Sharing does not make ordinary JavaScript objects globally accessible. GC pauses and a process failure can affect all contexts; use external coordination for application data that must be shared.

Architecture comparison

This compares independent-process scaling with Elide’s multi-context model; other runtimes can also offer worker-thread models. Shared infrastructure can reduce duplication, but application work and context-local state still scale with the workload.

Telemetry infrastructure is amortized across contexts; per-request instrumentation still costs work. Telemetry export was disabled for these measurements. Neither telemetry savings nor memory savings were measured by the HTTP benchmark.

The peak benchmark also explicitly selects inline scheduling and io_uring, uses unlimited memlock, and pipelines requests. The simple command above does not enable all those benchmark settings. The download contains the exact command and environment; performance tuning explains the application-facing context setting. This diagram describes architecture, not measured memory savings.

Benchmark environment

These details apply to the October 15 JavaScript startup and HTTP measurements. The older Python recording has only the machine information listed in its own section; do not infer the same kernel or distro for it.

Default server CPUs: 0-11,24-35; client: 12-23,36-47. Peak server CPUs: 0-2,6-8,12-14,18-20,24-26,30-32,36-38,42-44; client: 3-5,9-11,15-17,21-23,27-29,33-35,39-41,45-47. The differing masks preserve the same physical-core budget; they are recorded, not assumed interchangeable.

Run them yourself

Download the rerunnable benchmark package (SHA-256). It includes a Makefile, a dependency-free Python runner, JavaScript fixtures, the pipelined wrk client, raw results, and instructions. Bring Linux, Python 3, Make, util-linux, wrk, and your runtime binaries. No runtime binaries are bundled; use the recorded version and checksum for an exact binary match, or record your own version when comparing.

make run ARGS="--mode peak --binary /path/to/elide --contexts 24 --server-cpus YOUR_SERVER_CPUS --client-cpus YOUR_CLIENT_CPUS --out results"

Choose CPU masks for your machine. The download documents locked-memory limits, namespace differences, and commands for the default Elide, Bun and Deno comparison. Results vary with hardware and configuration.

The same files and commands work on any machine; expect different absolute numbers. Performance Tuning covers the setup: real binaries rather than version-manager shims, pinning the server and wrk to separate cores, and a warmup run before measuring.

See also

• Performance tuning for the settings that change speed and memory
• Comparisons per runtime: Node, Bun, Deno, Python