Performance
These are measurements, not promises: every number on this page comes from a benchmark or a measurement recorded while building the feature it describes, and each one says what was measured, how and when. Run them on your own hardware and your numbers will differ — the shape is what carries over.
- How long one run takes in each language, end to end
- What a flow step and a loop iteration cost
- Why parallel branches take the time of the slowest one
- How the figures were measured, so you can repeat them
What “fast” means here
A run is timed from the moment it is queued to the moment its result is recorded, using timestamps the database writes itself. That includes everything a person waits for: the queue, picking a worker, starting the sandbox, the code, and saving the output. Every benchmark runs with the sandbox ON, because that is how your code runs.
One run, per language
Measured: one script run on an idle fleet, sandbox on, timestamps written by the database (not a stopwatch on the client), median of repeated sessions on a freshly restarted fleet · July 2026 · waiso-bench exec benchmark.
JavaScript and TypeScript take the same path: TypeScript is compiled to the same JavaScript and both start in an isolated engine context that is already warm. Python takes a runner from a warm pool that has already loaded the platform’s SDK, so the script starts at once. C and C++ are compiled once and the binary is cached; the first run of a new version pays the compile, every run after it does not.
Under load
Measured: bursts of 32 runs against 3 workers with 12 slots each, sandbox on; median of 16 sessions (JavaScript, TypeScript) or 5 (Python, C, C++), each on a fresh fleet · July 2026. TypeScript and JavaScript are the same engine: at this burst a batch either clears in one wave or spills into a second, so the two trade places from session to session.
Flow steps and loops
Measured: the step-performance benchmark run alone against the live stack — a single Python step, a loop of 32 iterations, and an 8-step flow, start to recorded result · October 2026. A warm runner is reserved when a loop starts, so no iteration after the first wave pays a cold start.
A loop iteration costs about twice a single step because each iteration is its own job with its own sandbox: no state leaks from one item to the next. When iterations run in parallel (the loop’s degree), the loop’s total time is roughly the number of iterations divided by the degree, times one iteration.
Measured: a Parallel branches node with three Python branches sleeping 2 s, median of 5 runs on 3 workers · October 2026. The one-at-a-time bar is the sum of the three waits.
Script imports
Measured: 20 runs of a Python script, with and without importing a library from a folder of the same project · October 2026. Queued to done: 34 vs 36 ms.
The libraries a script imports travel with the job and are written next to it before the code starts, and the warm runner has already paid for the import machinery — so reusing code costs about one millisecond.
Repeat the measurements
- Measure with the sandbox on and from server timestamps; a client-side stopwatch adds its own network time.
- Restart the fleet between languages: a language measured after another inherits a warm system and looks faster than it is.
- Take the median of several sessions; a single burst near the slot capacity is noisy.
- Workers default to 12 slots each; more slots help runs that mostly wait, and change nothing for runs that keep the CPU busy.
| Figure | Value | When |
|---|---|---|
| One Python run alone | 21 ms | July 2026 |
| Flow step / loop iteration | 23 / 45 ms | October 2026 |
| Three 2 s parallel branches | 2.1 s | October 2026 |
| Import overhead | +1 ms | October 2026 |