pomai-studio
pomagrenate/rust-studio
Overview
A fast, lightweight, and hackable desktop IDE built from Rust for Rust developers using Tauri v2, Tree-sitter AST, and rust-analyzer. Replaces memory-heavy Electron wrappers and hallucinating statistical AI with deterministic compiler intelligence, sub-15µs typing latency, 30x Tree-sitter incremental re-parsing, and a sub-10MB OS resident memory footprint.
Benchmark SLA Scorecard (100% Pass Rate across 20 Suites)
Technologies & Concepts
Project Analysis
🔴 Problem
The memory & latency tax of Electron editors: Mainstream code editors routinely consume 1GB to 3GB+ of RAM even when idle. When opening large codebases or 100,000+ line files, naive text buffers (contiguous strings or flat arrays) freeze during keystrokes because inserting a single character triggers an $O(N)$ memory copy of several megabytes.
UI stutter from full-document AST re-parsing: When syntax highlighters re-parse an entire document from scratch on each edit, parsing a 1,000-line file takes 9ms–15ms. In a 60 FPS animation loop (where each frame must complete within 16.6ms), dropping 10ms on syntax trees leaves almost zero headroom for layout and rendering, causing noticeable typing lag and frame drops.
The cost and unreliability of probabilistic AI assistants: Cloud-based AI code assistants introduce latency (500ms–3,000ms per request), drain laptop battery, and require ongoing subscription fees. Worse, in a language with strict affine type systems and borrow checker rules like Rust, statistical models regularly hallucinate invalid lifetimes and non-existent crate methods.
⚪ Baseline
Standard Electron IDE characteristics:
- Idle memory usage between 1,200 MB and 2,500 MB RSS across browser render processes.
- Keystroke latency ranging from 25ms to 80ms under background language server activity.
- Full-document syntax re-parse times of ~9.27 ms on moderate source files.
- Document closing often leaves memory fragments due to JavaScript garbage collection delays.
- Heavy reliance on cloud LLMs with frequent type and borrow checker hallucinations.
🔵 Change
Engineered Pomai-Studio (Rust Studio) with Tauri v2 & Native Rust: Rather than bundling a full Chromium browser runtime, I combined a lightweight native Rust core with Tauri v2 and native OS WebViews to deliver a purpose-built Rust IDE.
Core architectural implementations:
- Logarithmic $O(\log N)$ B-Tree Rope Buffer: Integrated `ropey` to store document text as a balanced B-tree of small text chunks. Inserting or deleting characters at line 50,000 in a 100,000-line file touches only local tree nodes in microseconds, avoiding full-buffer memory reallocations.
- Subtree Tree-sitter Incremental AST Parsing:Configured Tree-sitter to record `InputEdit` byte deltas on each keystroke. Instead of discarding the syntax tree, the engine mutates only the damaged syntax subtree in under 350 µs—achieving a >30x speedup over full re-parsing.
- Prefix-Sum Viewport Virtualization: Implemented uniform layout resolution executing in 535 nanoseconds, rendering only the 50 visible lines in the viewport for silky 60+ FPS scrolling across files with hundreds of thousands of lines.
- Deterministic Zero-AI Compiler Intelligence: Sits directly on top of `rustc`, `rust-analyzer`, and `cargo clippy --message-format=json`. Provides instantaneous (0ms–10ms) diagnostics, automated machine-applicable clippy fixes, and concrete AST quick-fixes with 100% compile-correctness and complete offline privacy.
- Zero-Leak Document Cache Engine: Built a document cache manager where closing files immediately reclaims 100% of buffer heap allocations with 0.00 KB residual leaks.
🟣 Measurement
Rigorous Automated Benchmark Suite: Executed 20 benchmark tests spanning speed, memory allocation, and stability endurance on 2026-09-12 with precise Windows OS performance counters (`K32GetProcessMemoryInfo`).
Strict target SLAs and results:
- Keystroke typing latency (100k lines): Target < 50.00 µs → Measured
3.14 µs(PASS) - Massive file typing (500k lines / ~18MB): Target < 50.00 µs → Measured
3.20 µs(PASS) - Tree-sitter incremental re-parse: Target < 350.0 µs (> 20x speedup) → Measured
307.7 µs vs 9.27 ms full (30.1x speedup)(PASS) - Rope buffer overhead ratio: Target < 1.45x raw bytes → Measured
1.13x (3.59MB Rope / 3.16MB Raw)(PASS) - 50 open files cache scaling: Target < 6.00 MB → Measured
1.82 MB(PASS) - Memory reclaim on close: Target < 100.00 KB → Measured
0.00 KB residual(PASS) - Peak OS working set (RSS): Target < 250.00 MB → Measured
8.80 MB(PASS) - 20,000-operation mutation fuzzer: Target 0 panics → Measured
100.0% integrity (0.13s, 0 panics)(PASS) - 8-thread concurrent hammer: Target 0 deadlocks → Measured
93,835 ops/s (0 race conditions)(PASS)
🟢 Result
Microsecond typing responsiveness: Typing remains instantaneous at 3.14 µs regardless of file length, completely eliminating input lag even in massive 500,000-line codebases.
30x faster syntax updates: Incremental Tree-sitter re-parsing updates the concrete syntax tree in ~308 µs, offloading the main UI thread and preserving smooth 60 FPS rendering.
Minimal memory footprint: With a peak OS RSS of under 9 MB and 50 open documents consuming less than 2 MB of heap, the editor operates with less than 1% of the RAM footprint of typical Electron IDEs.
Benchmark Evidence & Visual Analytics
Official Performance, Low-Memory & Stability Benchmark Dashboard
The comprehensive benchmark dashboard demonstrating a 100% SLA pass rate across 20 test suites, a total execution time of 1.65 seconds, and a peak OS working set of only 8.80 MB.
Microsecond Typing & Viewport Latency Breakdown
Latency measurements confirming 3.14 µs typing latency on 100,000 lines, 3.20 µs on 500,000 lines, 43.31 µs 50-line viewport slice extraction (0.3% of a 60 FPS frame), and 535 ns prefix-sum layout calculation.
Tree-sitter Incremental AST Reparse vs. Full Parse Speedup
Incremental subtree re-parsing completes in 307.7 µs compared to 9.27 ms for full document re-parsing—a 30.1x speedup that guarantees zero UI stutter during high-speed typing.
Memory Allocation & Document Heap Overhead Scaling
Memory scaling showing 1.13x Rope overhead (3.59 MB Rope / 3.16 MB raw), 3.59 MB heap for 100,000 lines, 1.82 MB for 50 open files, and 0.00 KB residual leaks upon closing documents.
Endurance, Mutation Fuzzing & Concurrent Hammer Stress Testing
Stress testing validating 20,000-operation random mutation fuzzing with 100% integrity (0 panics), 8-thread concurrent hammer throughput of 93,835 ops/s, 2.59 µs degenerate 250KB line handling, and only 29 KB heap growth across 10,000 mutation cycles.
🟡 Lesson
Algorithmic complexity determines editor responsiveness: In my earlier exploration with text editing, I initially used flat strings. On small snippets, everything felt instant, but once a file exceeded 50,000 lines, inserting a single character caused noticeable lag. Moving to a B-tree Rope showed me how $O(\log N)$ operations fundamentally isolate typing performance from document size.
Incremental parsing is mandatory for smooth UI:When I first wired up syntax highlighting, running full-file AST parses caused frame drops whenever I typed quickly. Feeding byte-level edits into Tree-sitter's incremental parser reduced re-parse times from 9.27 ms down to 307 µs, making the editor feel butter-smooth.
Deterministic compiler tooling beats probabilistic guesses: Relying directly on `rust-analyzer` and `clippy` for error checking and refactoring taught me that developers write code much faster when diagnostics are 100% syntax and lifetime correct, rather than sorting through AI suggestions that introduce borrow checker errors.