Lode Performance Benchmarks: Startup & Memory on Apple Silicon

Measured on an Apple M1 Max, Lode’s warm-start median is 0.27 s, idle memory is ~106 MB, and the installer is 11.6 MB. This post lays out the method, the raw numbers, and a reproducible script — how the numbers were obtained matters more than the numbers themselves.

File tools (folder compare, hex viewer, full-text search) are used in a high-frequency, short-duration pattern: opened dozens of times a day, used for seconds at a time. In that pattern, “how long until it’s usable” and “how much memory it idles at” are the two metrics you feel most — and exactly where native beats Electron most clearly.

Test Environment

These are a single-machine, single-version snapshot — not cross-device statistics. The point is reproducibility: you can run the same script on your own Mac to verify.

1) Startup Time

Method: a script times from open-ing Lode to the moment its main process is up and a new WebKit WebContent child process appears — a proxy for “UI interactive.” Each run quits and relaunches (warm start), repeated 5 times.

The first run (0.368 s) is slightly higher because caches haven’t warmed up right after a quit; it then stabilizes around 0.27 s. This is the warm-start automated figure; a true cold start (first launch after reboot) will be a bit higher but still feels under a second in practice.

For context, a typical Electron app loads a full Chromium engine plus a Node runtime on every launch, usually landing at 2–5 seconds (a common published observation, not measured here).

2) Idle Memory

Method: vmmap --summary <pid> gives each process’s Physical footprint (Apple’s real memory metric, more accurate than RSS). Lode is a Tauri + WKWebView app, so it has a main process plus WebKit child processes — you must sum them for the true footprint. Measure with only Lode open and no file loaded (idle baseline), and close Safari and other apps that spawn WebKit processes.

About 106 MB at idle is light for a native GUI tool. Against a typical Electron baseline of 150–300 MB (a published observation), the gap compounds when several tools are open — the memory each app saves approaches 1 GB across an 8-app developer setup.

⚠️ Measurement pitfall: com.apple.WebKit.WebContent is a shared process name across all WKWebView apps. If Safari or another Tauri/WebView app is open during measurement, its children get miscounted. For a clean number, keep only Lode running.

3) Install Size

Because Lode uses the system WebView instead of bundling Chromium, the installer is about 12 MB. An equivalent Electron app’s installer often runs 80–150 MB or more — faster to download, smaller on disk, smaller incremental updates.

Reproducible Methodology

These numbers aren’t marketing copy — they come from a script you can run yourself. The core logic is two snippets.

Startup — time from open to main process + new WebContent:

# Snapshot WebContent processes that exist *before* launching Lode,
# then open Lode and poll until both the Lode main process and a
# *new* WebContent process appear.
before=$(pgrep -f "WebKit.WebContent")
open -a Lode
# ... time until pgrep -f "Lode.app/Contents/MacOS/" AND a new WebContent appears

Memory — sum Physical footprint across all Lode-related processes:

for p in $(pgrep -f "Lode.app/Contents/MacOS/") \
         $(pgrep -f "WebKit.WebContent") \
         $(pgrep -f "WebKit.Networking"); do
  vmmap --summary "$p" | grep "Physical footprint:"
done

From Rex’s experience: I insist on measuring Physical footprint rather than a glance at Activity Monitor because a Tauri app’s memory is split between the main process and the WKWebView children — looking at the main process alone badly underestimates it. My first version of the script even hit a bug: matching the process by the name Lode failed (the real process name is lowercase lode), so startup detection timed out every run. Switching to a bundle-path match (Lode.app/Contents/MacOS/) fixed it. The measurement tool itself needs debugging before the numbers can be trusted.

Summary Table

FAQ

Q: Are these cold-start or warm-start numbers? A: The 0.27 s in the table is the warm-start (quit-then-relaunch) automated median. A cold start (first launch after reboot) is a bit higher but still feels under a second; a formal frame-by-frame measurement (screen recording) will follow.

Q: Why is memory higher than the “Tauri is tiny” reputation? A: Because WKWebView spawns separate WebContent / Networking processes; summing them gives the true ~106 MB. Looking at the main process alone (36 MB) underestimates. Even so, it’s well below Electron’s 150–300 MB baseline.

Q: What about numbers on Intel Macs? A: Lode’s public distribution (Direct Sale / GitHub) is currently the Apple Silicon native build, and all figures here are from Apple Silicon — Intel isn’t covered.

Q: Can I reproduce this? A: Yes. Use the logic in the two snippets above on your own Mac. Before measuring memory, keep only Lode running and close Safari and other WebView apps.

Further Reading

• Why Native macOS Apps Beat Electron for File Tools
• Lode vs Araxis Merge deep dive
• ripgrep GUI for Mac
• Lode Features
• Apple vmmap: man vmmap
• Tauri docs: tauri.app