Performance

pipedog and Pipecat run the same pipelines: a frame goes through the same processors, the same queues and the same PipelineWorker. This page measures what that costs on each runtime, offline (the framework alone) and against Gemini (a real service, where the network dominates).

Every scenario is written twice, once against each framework, in the same shape: tools/bench/perf/pipedog.ts and tools/bench/perf/pipecat_bench.py. Pipecat runs from the upstream commit pipedog is ported from. Both log at WARNING. pipedog runs from a bundle made with bun build, as it is deployed. The runtimes take turns within each round, so a slow minute on the network or on the machine falls on all of them.

ResultsCopy Anchor Link

Frame processingCopy Anchor Link

10 pass-through processors in a PipelineWorker. Throughput: 20,000 TextFrames queued at once. Latency: one frame at a time, queued to arrival at the end of the pipeline. In brackets: compared with Pipecat (higher is better).

Cold startCopy Anchor Link

From starting the process to a pipeline that has started and ended, with the Google services loaded (for workerd: from starting workerd serve to the response). Runtime alone is the same for an empty program, so the difference is what loading the framework and running the pipeline cost.

Gemini LLM: time to first tokenCopy Anchor Link

GoogleLLMService with gemini-3.5-flash-lite (thinking at its minimum, as the service sends by default), from queueing an LLMContextFrame to the first LLMTextFrame at the end of the pipeline. SDK alone is the same request made with the Google GenAI SDK of the same language, in the same process, alternating with the pipeline.

Gemini TTS: time to first audioCopy Anchor Link

GeminiTTSService with gemini-3.8-flash-tts, from queueing a TTSSpeakFrame to the first TTSAudioRawFrame at the end of the pipeline, and the same request made with the SDK.

Measured 2026-10-22 on Apple M4 Pro (12 cores, 24 GB), darwin 25.6.0: pipedog 0.8.0, Pipecat 5558d26dca (pinned upstream) on CPython 3.13.13, Bun 1.4.2, Node 24.14.0, Deno 2.9.5, workerd 1.20261005.1. 6 rounds, runtimes taking turns.

Reading the numbersCopy Anchor Link

Frame processing is the framework alone: no I/O, no models. It's what a pipeline spends moving frames between processors, so it sets the floor under every response. In a voice bot each audio chunk (every 10–20 ms) and each LLM token goes through it.

Workers run pipedog's event loop the slowest of the JavaScript runtimes. Its timers and setImmediate wait about a millisecond, so @pipedog/asyncio yields through a body read instead, and a frame takes several such yields across 10 processors. That is still well under a millisecond per frame.

Peak memory in the JavaScript runtimes is mostly garbage the collector hasn't reclaimed yet, not memory in use. With 20,000 frames sent through, the live heap after a forced collection grows by about 5 MB on Node, and drops back once the pipeline ends. CPython frees objects as soon as the last reference goes, so its peak stays closer to what it holds. Under memory pressure V8 collects earlier; --max-old-space-size caps it.

Cold start matters for serverless (a Worker or a function that starts per call) and for scaling out. Pipecat's is mostly importing Python modules (here with the Google services). A bundle loads in one read.

Gemini times are dominated by the network and the model, which vary by hundreds of milliseconds from one request to the next. The SDK alone column makes the same request with Google's SDK, in the same process, right before or after each pipeline request. The paired difference is the framework's share, and is mostly within the noise for both frameworks. TTS services send audio downstream in chunks of a fixed size (as Pipecat does), so the first audio frame waits for the first full chunk, while the SDK column stops the clock at the first byte.

Telephony audioCopy Anchor Link

On a phone call, the bot's speech goes through the same steps on every call: the text-to-speech audio (usually 24 kHz) is resampled to the provider's rate (8 kHz for Twilio, Telnyx and others), μ-law encoded, and sent over a WebSocket in small messages paced in real time. These steps decide what the caller hears, so they are measured directly against Pipecat's.

Resampling and μ-lawCopy Anchor Link

Pipecat resamples with libsoxr at its highest quality (VHQ). pipedog can't load native code on every runtime, so it uses a windowed-sinc resampler compiled to WebAssembly (@pipedog/resampler-wasm), with a pure-TypeScript fallback. Both get the same test signal: three tones they must keep (300 Hz, 1 kHz, 2.5 kHz) and three above 4 kHz that a resampler going down to 8 kHz must remove. μ-law is checked bit for bit against Pipecat's (Python's audioop).

Each cell: everything besides the tones (noise, aliasing, distortion) / the largest single artefact, relative to the tones. Lower is cleaner; both are far below what can be heard.

μ-law: all 65,536 16-bit values encoded: identical to Pipecat's; all 256 codes decoded: identical.

PacingCopy Anchor Link

A bot plays two 6-second utterances through the WebSocket server transport and the Telnyx serializer, and a separate process standing in for Telnyx records when each audio message arrives. The dropouts are what a playback buffer of that size would run out of: silences a caller would hear. Each case runs with the bot's event loop idle and kept busy by other work, standing in for VAD, other calls and LLM streaming. Both frameworks use the same pacing code; the message sizes differ because libsoxr's stream resampler returns audio in blocks, while pipedog's returns it sample by sample, so pipedog sends a small message about every 40 ms and Pipecat a larger one every 120–160 ms. Telephony providers buffer more than 40 ms, so neither drops audio in practice.

Running itCopy Anchor Link

bun install
GOOGLE_API_KEY=... bun run bench:perf --write   # without a key, the Gemini scenarios are skipped
bun run bench:perf --runtime bun,python --scenario hop --rounds 1
bun run bench:audio --write    # resampling and μ-law against Pipecat's
bun run bench:pacing --write   # telephony pacing (--runtime, --load to narrow it down)

The first run creates a Python 3.13 environment with uv and installs Pipecat from the pinned upstream checkout (bun run upstream restores it). --write saves the raw samples to tools/bench/perf/results.json and the tables above. Model inference (Silero VAD, Smart Turn) has its own benchmark, bun run bench; its results are in the @pipedog/onnx README.