A Critique of GPUI and egui State Models for Complex Desktop Applications

In a benchmark of a UI containing 3,000 live rows, changing a single label in the GPUI framework took 8.4 ms, a cost that scales linearly with the size of the UI tree rather than the size of the state change. This performance ceiling suggests that while frameworks like GPUI and egui offer attractive, simple APIs, their underlying state models may be 'dead ends' for large-scale native desktop applications.

This graph illustrates the linear performance scaling described in the benchmark results for GPUI.

The Problem of UI Incrementalization

Every UI framework must eventually decide what code to run when a single value changes. If a framework cannot identify the specific dependencies of a UI component, it must re-run larger portions of the UI tree, leading to performance degradation as the application grows.

The author compares several models: immediate mode (egui) runs all UI code every frame; Elm (Iced) runs the entire view function and diffs the result; and GPUI uses a 'notify' system. However, because Rust lacks a write barrier on mutable references, GPUI's notify system can only signal that *something* might have happened, forcing it to re-render every view not protected by a specific cache boundary.

“Take the precision and you lose the pleasant API.”

— A Critique of GPUI

Benchmarking the Scaling Wall

To demonstrate these limitations, the author conducted benchmarks on a sparse state change in a large UI. In GPUI, a hover or keystroke cost the same as a value write because the cost follows the tree structure. When rows were written as plain elements without caching, a single label update jumped from 8.4 ms to 92 ms.

A hand-written equality guard reduced that 92 ms cost to 0.9 µs, highlighting the performance left on the table. While the Zed editor feels fast, the author notes it bypasses GPUI's layout and view semantics for its text editor, meaning its performance may not reflect the framework's inherent limits in other contexts.

This figure explains the limitations of retention-based models discussed in the scaling analysis.

Chart drawn by HN Digest from figures reported by blog.zortax.de; values are shown as written in the source.

The Trade-off Between Simplicity and Precision

The author argues that making GPUI precise enough to scale requires a shift toward a signal-based model, where components are separately owned entities with subscriptions. This creates a 'signal graph' built by hand, which is more complex to reason about than GPUI's current 'plain function' approach.

This visual clarifies the trade-off between tracking precision and actual execution overhead.

Similarly, the Elm architecture provides a single source of truth but becomes difficult to manage at scale. In complex apps, the logic for a single value (like an unread count) can become spread across every message variant, making it harder to maintain than a centralized signal definition.