Claims like “fast” and “lightweight” are easy to type and hard to check. This page publishes the numbers we actually measure, how they’re measured, and the architectural guarantee that keeps them from quietly regressing. Everything here comes from an automated performance suite that runs against every change — not from a one-off benchmark screenshot.
The numbers
Measured 2026-07-23 on an Apple M4 MacBook (16 GB RAM), macOS:
| Metric | Measured |
|---|---|
| Cold start → interactive | ~0.8 s (process spawn to a usable editor shell) |
| Idle memory, whole app | ~490 MB (sum of every process’s working set) |
| UI shell re-renders per run | 0 (enforced exactly — see below) |
Your machine will produce different absolute numbers — these are honest points of reference, not guarantees. We re-measure and update this page when the numbers move meaningfully.
How each number is measured
Cold start is wall-clock time from spawning the process to the app shell being visible and interactive — not “first paint” of a splash screen. There is no login gate, no cloud sync, and no license check on the startup path, which is most of why the number is small.
Idle memory is the sum of the working sets of all of Bandura’s processes — main, renderer, GPU, and utility — sampled after startup work has settled. That’s the same total you’d get adding up the app’s rows in Activity Monitor or Task Manager. We publish the all-processes sum because single-process figures make any Chromium-based app look about a third of its real size.
Bandura is an Electron app, and we’d rather be straight about what that means: the baseline includes a Chromium renderer and a bundled code editor (the same Monaco editor VS Code uses). The number above is the whole truth, not the flattering slice of it.
The guarantee behind the numbers: run-time render isolation
The failure mode that makes API clients feel heavy usually isn’t startup — it’s what happens while your tests run. A 20-iteration loop emits hundreds of execution events; if each event re-renders the whole window, the app churns CPU and memory for work the user never sees.
Bandura’s execution state is architecturally isolated from the application shell: run events reach only the surfaces that display them — the graph you’re watching, the console, the variables inspector. The file tree, sidebar, tabs, and the rest of the shell re-render zero times during a run.
That zero is not a design intention — it’s an exact assertion in our end-to-end suite. A test runs a 20-iteration loop flow and fails if the shell re-renders even once. If a future change couples the shell back to run state, the suite goes red before the change ships.
What this means in practice
- Leaving Bandura open all day costs you an idle editor, not a growing one — there is no background sync engine and no cloud session to keep warm, and nothing phones home unless you explicitly opted in (error reporting is off by default).
- Long runs and big batches stress the execution engine, not your window manager.
- The suite that produces these numbers also guards them, so “it got slow after the update” is a bug we can catch before release, not after your tweet.
Related: Run & debug flows · Execution history