Performance

The parity performance suites use the same scenario layout across Python, TypeScript, Rust, and Go:

uv run tests/performance_runtime.py --no-json
pnpm --dir abxbus-ts run perf:node
cargo test --manifest-path abxbus-rust/Cargo.toml --release --test test_eventbus_performance -- --nocapture
(cd abxbus-go && go test ./tests -run TestPerformance -count=1 -timeout=180s -v)

Measured locally on the same development machine used for the parity runs:

Runtime	1 bus x 50k events x 1 handler	500 buses x 100 events x 1 handler	1 bus x 1 event x 50k parallel handlers	1 bus x 50k events x 50k one-off handlers	Worst case (N buses x N events x N handlers)
Python	`0.366ms/event`, `0.188kb/event`	`0.408ms/event`, `0.153kb/event`	`0.093ms/handler`, `10.197kb/handler`	`0.633ms/event`, `0.145kb/event`	`0.504ms/event`, `4.171kb/event`
Rust	`0.067ms/event`	`0.070ms/event`	`0.062ms/handler`	`0.077ms/event`	`0.227ms/event`
Go	`0.016ms/event`	`0.011ms/event`	`0.085ms/handler`	`0.011ms/event`	`0.041ms/event`
TypeScript (Node)	`0.065ms/event`, `4.145kb/event`	`0.078ms/event`, `1.562kb/event`	`0.065ms/handler`, `11.631kb/handler`	`0.123ms/event`, `2.182kb/event`	`0.344ms/event`, `12.619kb/event`

Notes:

Python and TypeScript memory numbers are peak RSS deltas from their runtime harnesses.
Rust and Go performance tests currently assert the 0.300ms per event/handler budget for the measured scenarios but do not report per-event memory in the README matrix.
Rust’s 50k parallel handler budget is measured with cargo test --release; the debug build still runs the other Rust performance scenarios and ignores only that release-sensitive stress case.
The current local Python row and TypeScript worst-case row are above the target budget in some scenarios and should be treated as performance follow-up items rather than baseline targets.

Getting Started

Features

API Reference

Concurrency Control

Integrations

Further Reading