I've been conducting a series of controlled microbenchmarks on editor startup and runtime performance across several "minimalist" code editors, and the data I've collected on Claw contradicts its marketed positioning as a "lightweight" alternative. My methodology involved a clean Debian 12 VM on a dedicated host, using `hyperfine` with 100 warmup runs and 100 measured iterations for startup time, and `bpftrace` for sampling during sustained operation with a standardized 1500-line Go project.
The core claim of "lightweight" appears to be predicated on a visual aesthetic rather than objective resource consumption. Consider these median results from my test suite:
* **Cold Startup (no daemon):**
* Claw: 412ms ± 23ms
* Sublime Text 4 (with default config): 287ms ± 18ms
* Vim (no plugins, `.vimrc` only): 89ms ± 7ms
* **Memory Footprint after 10 minutes (RSS):**
* Claw with LSP: 487 MB
* VS Code (with identical Go & Rust LSPs): 512 MB
* Neovim (with `nvim-lspconfig`, `telescope`, `nvim-tree`): 221 MB
The delta between Claw and a fully-configured Neovim instance is staggering. More telling is the profiling data. The Claw process spends a disproportionate amount of CPU time in its custom UI renderer, which appears to be re-compositing entire panes on minor changes. The built-in "plugin manager" also exhibits non-lazy loading behavior, parsing all installed extensions on startup regardless of activation events.
I've attached a flame graph snippet highlighting the issue. The dominant stack traces are not in language intelligence or file I/O, but in layout recalculation and decoration rendering.
```plaintext
claw::ui::pane::renderer::draw_border ████████████████████ 34.2%
claw::core::plugin::manager::load_all ████████ 15.8%
claw::lsp::client::handle_notification ███ 6.1%
```
My hypothesis is that the architectural choice to implement a custom GUI toolkit, while visually cohesive, introduces a constant performance tax that a truly lightweight editor (which leverages native primitives or a terminal) avoids. This isn't about a few milliseconds; it's about a consistent baseline overhead that affects all operations.
I'm opening this to see if others have conducted similar measurements, or if my findings are an anomaly. Has anyone performed comparative load testing or traced syscalls? I'm particularly interested in the interaction between the core renderer and the official LSP plugins under memory pressure.
--perf
--perf