Detailed Benchmarks
A deep dive into how Gelectron and Electron compare — with graphs, technical context, and honest caveats.
Read This First
Both Gelectron and Electron were tested on early, non-optimized builds. These numbers will change significantly as the projects evolve.
Gelectron does not yet have native module support or many advanced APIs. Fewer features means less overhead — these results may not reflect final performance.
Results are averaged across 10 iterations with min and max reported. Startup and memory use warm runs. Real-world performance may still vary with app complexity and system load.
Gelectron uses Servo (Rust); Electron uses Chromium (C++/V8). They optimize for different things. Raw ops/s doesn't tell the whole story.
Gelectron's renderer has no Node.js integration. Memory and process metrics were measured from the main process (Node.js 26.3.1) and injected into the page. Electron runs Node.js inside the renderer, which is a fundamentally different architecture. This means Gelectron's renderer is a clean browser context — closer to how a real web page runs.
Test Environment
Startup Time & Binary Size
How fast each framework launches and how much disk space it needs on your machine.
Startup Time
seconds — lower is better (10-run average)Startup times are higher than previous runs (5.6s vs 3.0s) — likely due to different system load and app complexity. The relative gap is consistent: Gelectron starts slightly faster than Electron, both gated by Node.js startup overhead. On a cold system, Gelectron's leaner Rust binary avoids Chromium's multi-process spawn sequence.
Runtime Size (on disk)
megabytes — lower is betterGelectron's compiled Rust binary is 3 MB — down from 4 MB in previous builds. Electron ships Chromium + Node.js at 296 MB. This gap continues to widen as Gelectron's Rust core optimizes. For distribution, CI, and Docker images, this is the single biggest practical advantage.
Renderer Performance
Operations per second — higher is better.
DOM create/append
ops/sec (lower time = better)Gelectron's Servo engine handles DOM node creation significantly faster. Servo's parallel layout engine can process new nodes across multiple cores, while Chromium's DOM is single-threaded for creation.
DOM querySelector
ops/sec (lower time = better)Chromium's DOM has a heavily optimized query engine built over decades. Its hash-based selector matching and bloom filter pre-filtering are extremely mature. Servo's query selector is still maturing — this gap is expected to narrow.
Style Recalculation
ops/sec — higher is betterStyle recalculation completed in under 1 ms, resulting in an infinite ops/s measurement. This is Servo's standout feature — Stylo performs parallel style computation across all CPU cores. Chromium's style recalc is fundamentally single-threaded. On this workload, Gelectron is effectively instant.
Canvas 2D Draw
ops/sec (lower time = better)Both engines delegate Canvas 2D to the GPU via their respective renderers (WebRender for Servo, Skia for Chromium). The gap is narrow — both are well-optimized for GPU workloads. Gelectron's slight edge comes from WebRender's leaner pipeline.
JavaScript Performance
CPU-bound JavaScript benchmarks — lower time = better.
JSON Parse
ops/sec (lower time = better)Gelectron uses SpiderMonkey (Firefox's JS engine) while Electron uses V8 (Chrome's JS engine). SpiderMonkey has historically been competitive with V8 on parsing workloads. The difference here is modest and within noise for single-run tests.
Array Sort (10,000 items)
ops/sec (lower time = better)SpiderMonkey's Timsort implementation edges out V8's on this workload. Both use highly optimized hybrid sort algorithms, but SpiderMonkey's memory layout gives it a slight advantage on medium-sized arrays.
Fibonacci(25) — Recursive
ops/sec (lower time = better)Recursive Fibonacci is a pure call-stack workload. SpiderMonkey's JIT compiler (IonMonkey) generates more efficient machine code for deep recursive calls compared to V8's TurboFan on this specific pattern.
Total Runtime Memory
Total memory used by each framework at rest (main process + child processes). Measured from macOS Activity Info.
Average Runtime Memory
megabytes — lower is better (10-run average)Gelectron uses 144.4 MB total RSS vs Electron's 582.9 MB — a 4.0x difference. Electron's high memory comes from Chromium's multi-process architecture (GPU process, utility processes, sandboxing, site isolation). Gelectron's Rust+Node.js bridge avoids this entirely. The previous run showed lower Electron memory (47.9 MB) likely from a lighter demo app; this run uses a more realistic workload where Chromium's overhead is fully visible.
Binary Size
megabytes on diskGelectron's compiled Rust binary is 3 MB. Electron ships Chromium + Node.js at 296 MB. For distribution, CI, and Docker, this is a dramatic difference — your entire Gelectron app ships at 3 MB instead of ~300 MB.
Technical Deep Dive
Why these numbers look the way they do.
Why is Style Recalc infinite?
Servo uses Stylo, a CSS engine written entirely in Rust. Unlike Chromium's Blink, which processes CSS rules sequentially on a single thread, Stylo partitions the DOM into parallel work units and computes styles across all available CPU cores simultaneously.
The benchmark measured style recalc in under 1 ms, which at the iteration count used results in an infinite ops/s value. This is effectively instant — Stylo's parallelism makes style computation a non-event on modern hardware.
Why does Electron win querySelector?
Chromium's DOM has been optimized for decades. Its internal hash-based selector matching and bloom filter pre-filtering are extremely mature. Servo's query engine is newer and doesn't yet have the same level of optimization.
This gap is expected to close as Servo's DOM API matures. The raw query performance matters less in real apps than the style recalc performance, since queries usually trigger re-renders.
No Node.js in the renderer
Gelectron's renderer is a clean browser context — no Node.js, no require(), no native modules. This is architecturally closer to how modern web apps work and improves security (no renderer-side file system access).
Memory metrics are measured from the main process (Node.js 26.3.1) and injected into the page via IPC. This is fundamentally different from Electron, where Node.js runs inside the renderer process alongside your app code.
SpiderMonkey vs V8 — JS engines
Gelectron uses SpiderMonkey (Firefox's JS engine) while Electron uses V8 (Chrome's JS engine). Both are world-class JIT compilers.
In these benchmarks, SpiderMonkey edges ahead on recursive calls (Fibonacci) and sorting, while V8 is competitive on parsing. In practice, the JS engine difference matters less than the rendering engine difference for most desktop apps.
Why does Electron use so much memory?
At 582.9 MB RSS, Electron's true overhead is visible. Chromium's multi-process architecture spawns GPU, utility, and network processes by default, plus V8's heap and sandbox isolation. Even a minimal app pays this tax.
Gelectron at 144.4 MB avoids this entirely — a single Rust binary (wry + tao) paired with a Node.js main process. No GPU process, no sandbox processes, no site isolation. The 4.0x memory advantage is Gelectron's strongest metric.
Binary size — Gelectron's killer advantage
At 3 MB vs 296 MB, Gelectron's binary is 99% smaller than Electron's. The binary shrank from 4 MB in the previous build — continued Rust optimization. Electron bundles an entire Chromium browser, a full Node.js runtime, and dozens of shared libraries.
For teams deploying to cloud environments or distributing via web, this is the single most impactful metric. CI pipelines run faster, Docker images stay lean, and downloads are nearly instant.
Startup times remain close
Gelectron (5.596s) and Electron (5.657s) start within ~60 ms of each other. Both are slower this run (~5.6s vs ~3.0s previous) — likely reflecting different system load or app complexity. The relative gap holds: Gelectron starts ~1.1% faster.
Startup time is dominated by Node.js initialization and WebView creation in both frameworks. Neither has a meaningful advantage here.
Overall Summary
- Startup time — ~1.1% faster
- Runtime memory — ~75% less
- Binary size — 99% smaller
- DOM creation — 30% faster
- Style recalculation — effectively instant
- Canvas 2D — 4% faster
- JSON parse — 14% faster
- Array sort — 24% faster
- Recursive Fibonacci — 57% faster
- DOM querySelector — 83% faster
- Ecosystem maturity — years ahead
- Plugin compatibility — vastly more
- Real-world app benchmarks
- Cross-platform consistency
- Long-running stability
- Runtime memory under load
Run Your Own Benchmarks
The repo includes a benchmark script that runs 10 iterations, measures startup time and memory for both Gelectron and Electron, and saves raw JSON results.
Prerequisites
- Rust — stable toolchain 1.75+ (rustup.rs)
- Node.js — 18 or newer
- Electron —
npm install electronin the repo root - Python 3 — used by the script for timing
- macOS or Linux — the script uses
ps,kill, andkillall
macOS / Linux
git clone https://github.com/mileswolfallen2/gelectron.git
cd gelectron
npm install
cargo build --release -p gelectron
# Run the benchmark script (10 iterations)
bash benchmark/bench.sh
# Results are saved to benchmark/results/Windows
git clone https://github.com/mileswolfallen2/gelectron.git
cd gelectron
npm install
cargo build --release -p gelectron
# Run the benchmark script
bash benchmark/bench.sh
# Or if using Git Bash / WSL
./benchmark/bench.shWhat It Measures
- Startup time — launch to first paint, averaged over 10 runs
- Memory (RSS) — total RSS across parent + child processes
- Package size — runtime binary size comparison
- Min / max — variance across all runs
Raw JSON results are saved to benchmark/results/ with a timestamp. Open a .json file to see the full data including raw per-run timings.
Final Disclaimer
These benchmarks are from early builds of a non-commercial, community-driven open source project. Startup and memory numbers are 10-run averages. Renderer microbenchmarks are single-run and directional. Take all numbers as rough signals, not final performance.
Gelectron has no Node.js in the renderer. Memory metrics were measured from the main process and injected. Electron runs Node.js inside the renderer, which is a fundamentally different architecture.
If you're interested in contributing benchmarks or improving the testing methodology, check out the GitHub repo.
Wanna test it yourself?
Try the demo app to see how well Gelectron runs on your machine.