jargo-benchmarks
June 25, 2026 · View on GitHub
Benchmarks comparing jargo (Go) with Pipecat (Python). Both sides drive the same workload through each framework's public API — a chain of pass-through processors with no work of their own — so the numbers are the cost of the frame-transport plumbing itself, the part where goroutines and a single asyncio event loop genuinely differ.
main.go— the Go side, using jargo as a library.python/bench_pipeline.py— the Pipecat side.
The two are written to mirror each other (same depths, frame counts, and metrics) so the comparison is apples-to-apples.
These are component micro-benchmarks. Real end-to-end conversational latency is dominated by network round-trips to the STT/LLM/TTS services, which are identical for both projects.
Run it
# jargo (Go) — needs Go; no cgo, the pipeline package is pure Go
go run .
# Pipecat (Python)
cd python && pip install -r requirements.txt && python bench_pipeline.py
Both print ns/hop (per-processor latency at depths 1/4/16/64) and frames/s
(aggregate throughput as simultaneous sessions scale). The Go side scales to
1000 sessions; the Python harness caps at 100, because one event loop cannot
finish 1000 in any reasonable time — that ceiling is itself the result.
What the numbers say
Indicative figures from one 16-core x86-64 Linux machine (Intel Ultra 7 255H). Micro-benchmarks are noisy; treat these as orders of magnitude and re-run on your own hardware.
Per-hop latency (one frame through one processor):
| Chain depth | Pipecat (Python) | jargo (Go) |
|---|---|---|
| 1 | ~547 µs/hop | ~14 µs/hop |
| 4 | ~235 µs/hop | ~8.8 µs/hop |
| 16 | ~134 µs/hop | ~8.2 µs/hop |
| 64 | ~109 µs/hop | ~7.5 µs/hop |
jargo's per-hop cost is goroutine wakeup latency; Pipecat's is an await through
each processor's asyncio queue plus its worker bookkeeping — jargo is ~15–40×
faster per hop.
Aggregate throughput as simultaneous sessions scale (4-processor chain):
| Sessions | Pipecat (Python) | jargo (Go) |
|---|---|---|
| 1 | ~1,100 frames/s | ~26,000 frames/s |
| 10 | ~1,000 frames/s | ~41,000 frames/s |
| 100 | ~1,000 frames/s | ~92,000 frames/s |
| 1000 | did not finish | ~123,000 frames/s |
This is the headline. Pipecat's throughput is flat — one asyncio event loop runs on one core, so adding sessions adds no capacity. jargo's throughput rises with sessions as goroutines spread across cores: ~92× more aggregate throughput at 100 sessions, and it keeps scaling. For a server hosting many concurrent voice calls, that is the difference between one box and many.
A note on turn-taking
The CPU/model-bound pieces (Whisper features, Silero VAD, Smart Turn) are not benchmarked here. Model inference routes through the same ONNX Runtime on both sides, so it measures glue, not language (a tie); and the parts that aren't model-bound (feature extraction) sit behind unexported internals on both frameworks, so they can't be measured through the public API the way this comparison is. The framework/concurrency comparison above is the meaningful one.