px0/benchmarks

// empirical performance & methodology

Performance Benchmarks

px0 is engineered for extreme responsiveness, instant code navigation, and low host resource utilization. Every benchmark here is empirical, reproducible via shell scripts, and evaluated across seven real-world repositories from Flask to the Linux Kernel.

<1 msCold startup timeSub-millisecond perceived boot
~20-30 MBHost Resident RAMSingle static Go binary
370 msLinux Kernel indexing95,710 files indexed in parallel
~90% lessSystem RAM vs Electron~100-180 MB total incl. tab
03/bench
// empirical benchmarks·7 repositories · Linux kernel to Flask

Measured, not claimed.

Every number here comes from ./benchmark.sh against shallow clones of seven real repositories. Linux, language servers off, fastest of five requests. Run it on your machine and paste the table anywhere.

~20-30 MBhost RSS
370 msLinux kernel (95k files)
~90% lessRAM vs VS Code
<1 mscold startup
multi-editor benchmark · identical hardware (Linux)~20 - 30 MB host RSS · ~100 - 180 MB total
editorprocess archhost / server rsstotal system ramtime to openfirst interact
px0Native Go daemon + Browser client~20 - 30 MB~100 - 180 MB~10 ms~15 ms
VimNative CLI~10 - 15 MB~10 - 15 MB~15 ms~15 ms
NeovimNative CLI~10 - 20 MB~10 - 20 MB~150 ms~150 ms
Sublime TextNative GUI (C++)~100 - 250 MB~100 - 250 MBGUI dep.~250 - 500 ms
ZedNative GUI (Metal / Vulkan)~200 - 450 MB~200 - 450 MBGUI dep.~300 - 600 ms
VS CodeElectron (Chromium + Node)~500 - 1,440 MB~1,100 - 1,440 MB~3.0 - 5.0 s~6.0 - 10.0 s
Note: CLI editors (Vim/Neovim) do not provide inline LSP out-of-the-box natively. Zed and Sublime Text evaluated as active GUI configs. px0 serves a full workspace with instantaneous indexing natively in 20-30 MB host RSS (~100-180 MB total system RAM including the browser tab).
accounting for the browser tab · client/server breakdown vs vs code~85 - 90% net system reduction
component / layervs code (desktop electron)vs code remote (code-server)px0 (local mode)px0 (remote server mode)
Server / Host Daemon~400 - 600 MB (Node.js, Extension Host)~500 - 1,200 MB (VS Code Server tree)~20 - 30 MB (Native Go binary)~20 - 30 MB (Host memory only)
Client UI / Frontend~700 - 900 MB (Bundled Chromium + GPU)~150 - 300 MB (Web browser tab)~80 - 150 MB (Single browser tab)~80 - 150 MB (Local client browser)
Total System RAM~1,100 - 1,440 MB~650 - 1,500 MB~100 - 180 MB (~85-90% reduction)~100 - 180 MB
Host Impact (Server / Devbox)N/A~500 - 1,200 MB~20 - 30 MB~20 - 30 MB
01
Total System Memory is ~90% Lighter

Even when adding the browser tab (~80 - 150 MB) to the Go backend (~20 - 30 MB), px0's total local system footprint is ~100 - 180 MB. Compared to Electron-based IDEs running at ~1,100 - 1,440 MB, px0 achieves an 85 - 90% net memory reduction.

02
Remote & Cloud Devboxes

On remote servers, cloud VMs, and containers, the host pays strictly the ~20 - 30 MB server cost while UI rendering runs on the client machine. In contrast, remote server IDEs consume 500 MB to 1.2 GB+ directly on the host.

03
Marginal Cost of an Existing Browser

Developers virtually always have a browser running. Adding one lightweight tab to an already-warm browser process pool avoids the steep CPU and memory penalty of cold-starting a dedicated, isolated Chromium instance and GPU process tree.

04
Virtualized DOM Keeps the Tab Bounded

px0 bypasses heavy third-party editor frameworks like Monaco or CodeMirror. A bespoke virtualized renderer mounts only ~60 active rows at any time regardless of file size, keeping client tab RAM strictly bounded (~80 - 150 MB).

real corpus · px0 standalonesorted by files indexed
repolangsourcefilesindexfuzzyfull scanopen bigreopenrsspeak
flaskPython3 MB2351 ms0.8 ms2.3 msn/an/a16 MB18 MB
redisC26 MB1,85513 ms1.0 ms18.2 ms80.8 ms1.2 ms17 MB27 MB
djangoPython74 MB7,01439 ms1.3 ms26.8 ms166.8 ms1.0 ms20 MB29 MB
reactJavaScript63 MB7,17852 ms2.7 ms32.2 ms57.7 ms0.7 ms21 MB28 MB
kubernetesGo370 MB25,926150 ms13.5 ms84.6 ms199.0 ms0.9 ms30 MB44 MB
typescriptTypeScript414 MB66,533566 ms6.2 ms150.3 ms40.9 ms6.5 ms69 MB105 MB
linuxC1,809 MB95,710370 ms6.0 ms451.8 ms26.7 ms0.6 ms55 MB73 MB
full scan searches for a string that matches nothing, so every indexed byte is read. the worst case.open big is the largest source file, cold. file length does not matter: only the visible window is lexed.
linux kernel · rss across a session−37 MB after idle

px0 reclaims memory after 15 s of inactivity, so an open session settles back down.

language server path · goplsserver ready 374 ms, paid once
document outline1.4 ms
go to definition1.5 ms
find all references3.0 ms
hover5.1 ms
px0 memory18 MB
gopls memory122 MB

Servers are separate processes, spawned on the first request for their language and shut down on exit. Without one, px0 falls back to a regex outline instantly.

$ ./benchmark.sh --clone && ./benchmark.shmethodology → BENCHMARKS.md
process model memory breakdown · vs code vs px01439 MB VS Code tree vs ~25 MB px0 daemon
VS Code Process Tree1439 MB

Individual processes spawned by default on a standard workspace:

extension host500 MB
language server350 MB
server main260 MB
IPC proxies & utility190 MB
PTY host & terminal71 MB
file watcher68 MB
px0 Core Daemon~20 - 30 MB

Single static native binary managing all subsystems in memory:

  • One Process ModelRouter, file indexer, parallel search pool, Chroma highlighter, and Git forge in one binary.
  • No Electron or Node RuntimeZero bundled Chromium instances, zero Node.js processes, zero CGO dependencies.
  • Active Memory ScavengingUnused heap pages returned to host OS via debug.FreeOSMemory() after 15 seconds of idle.
  • Lazy LSP SpawningLanguage servers spawn strictly on demand and terminate on process exit.
reproducibility instructions · shell scriptsrun locally on your workstation

We encourage developers and teams to verify all claims on their own hardware. The repository provides an automated benchmark harness:

1Clone the repository and benchmark corpus
git clone https://github.com/px0-ai/px0.git && cd px0
./benchmark.sh --clone
Performs shallow clones of all 7 test repositories into bench-repos/.
2Execute full benchmark suite across all repositories
./benchmark.sh
Runs 5 iterations per repository and emits a Markdown table with index, search, and memory statistics.
3Trace memory scavenging on the Linux kernel
./benchmark.sh --memory bench-repos/linux
Profiles RSS through index, 5 full-tree scans, opening large files, and idle scavenger reclamation.
4Evaluate language server (LSP) request latency
./benchmark.sh --lsp .
Benchmarks cold spawn latency, definition lookup, outline extraction, and symbol references with gopls.
test hardware specifications & methodologycontrolled environment parameters
Operating System
Linux 6.x (Ubuntu 24.04 LTS / Debian 12 x86_64)
Processor
AMD Ryzen 7 / Intel Core i7 (8 physical cores, 16 threads)
Memory
32 GB DDR5 RAM
Storage
1 TB NVMe PCIe 4.0 SSD (direct local filesystem mount)
Test Corpus
7 public open-source git repositories cloned at --depth 1
Run Protocol
Fastest of 5 consecutive runs (eliminates cold disk cache variance)
LSP Baseline
Language servers disabled (-no-lsp) for pure reader baseline
Scavenger Timing
debug.FreeOSMemory() invoked after 15 seconds of idle time
frequently asked questionsunderstanding the data

Why is the Linux kernel indexed faster than the TypeScript repository?

The TypeScript repository contains tens of thousands of deeply nested, generated AST test fixtures and large JSON snapshots. The Linux kernel consists almost entirely of flat, clean C source files and headers. px0 parallel directory walker traverses and ignores non-code files concurrently, achieving ~370 ms across the 95,710 Linux files.

How does px0 maintain ~20-30 MB host RAM without leaking memory?

px0 uses windowed lexical chunking (1,000-line blocks) and an active idle memory scavenger. 15 seconds after an indexing or search pass completes, px0 calls debug.FreeOSMemory(), explicitly returning unused heap pages directly back to the operating system kernel.

Does px0 include language server overhead in its memory benchmarks?

No. Just like in production, language servers (e.g. gopls, clangd) spawn lazily as separate OS processes only when an outline or definition is requested. Without an LSP installed, px0 provides instant regex-based outline fallback with zero extra RAM.

What is the real cost of the browser tab in local vs remote mode?

On local developer machines, the browser tab consumes ~80-150 MB for the DOM, V8 runtime, and GPU compositing. Total local footprint is ~100-180 MB (still 85-90% lower than Electron IDEs). When running remotely (px0 -host 0.0.0.0 on a devbox or container), the remote host pays strictly the ~20-30 MB Go daemon cost while UI rendering runs locally on your laptop.

Looking for systems architecture details?

Read about bounded goroutine pools, two-pass fuzzy ranking, and windowed Chroma syntax chunking.

Architecture Spec →Raw BENCHMARKS.md →