複雑なデスクトップアプリケーションにおけるGPUIおよびeguiの状態モデルに対する批判

3,000行のライブ行を含むUIのベンチマークでは、GPUIフレームワークにおいて単一のラベルを変更するのに8.4 msを要した。このコストは状態の変化の大きさではなく、UIツリーのサイズに比例して増加する。このパフォーマンスの限界は、GPUIやeguiのようなフレームワークが魅力的でシンプルなAPIを提供している一方で、その基礎となる状態モデルが大規模なネイティブデスクトップアプリケーションにとっては「行き止まり」である可能性を示唆している。

このグラフは、GPUIのベンチマーク結果で説明されている線形なパフォーマンススケーリングを例証している。

UIのインクリメンタル化の問題

すべてのUIフレームワークは、単一の値が変化したときにどのコードを実行すべきかを最終的に決定しなければならない。フレームワークがUIコンポーネントの特定の依存関係を特定できない場合、UIツリーのより大きな部分を再実行する必要があり、アプリケーションの成長とともにパフォーマンスの低下を招く。

著者はいくつかのモデルを比較している。即時モード（egui）は毎フレームすべてのUIコードを実行する。Elm（Iced）はビュー関数全体を実行して結果を差分比較する。そしてGPUIは「notify」システムを使用する。しかし、Rustにはミュータブルな参照に対するライトバリアがないため、GPUIのnotifyシステムは「何かが」起こった可能性があることしか通知できず、特定のキャッシュ境界で保護されていないすべてのビューを再レンダリングすることを強いることになる。

「精度を追求すれば、心地よいAPIを失うことになる。」

— A Critique of GPUI

スケーリングの壁のベンチマーク

これらの制限を実証するために、著者は大規模なUIにおける疎な状態変化のベンチマークを実施した。GPUIでは、ツリー構造に従ってコストが決まるため、ホバーやキー入力のコストは値の書き込みと同じであった。行をキャッシュなしのプレーンな要素として書き込んだ場合、単一のラベル更新のコストは8.4 msから92 msへと跳ね上がった。

手書きの等価性ガードによって、その92 msのコストを0.9 µsまで削減でき、残されていたパフォーマンスの余地を浮き彫りにした。Zedエディタは高速に感じられるが、著者はそれがテキストエディタにおいてGPUIのレイアウトおよびビューのセマンティクスをバイパスしていることに言及しており、そのパフォーマンスは他のコンテキストにおけるフレームワーク固有の限界を反映していない可能性がある。

この図は、スケーリング分析で議論されている保持ベースのモデルの制限を説明している。

HN Digestによる図表（blog.zortax.deの報告数値に基づく）。数値はソースの表記通り。

シンプルさと精度のトレードオフ

著者は、GPUIをスケール可能なほど精密にするには、コンポーネントがサブスクリプションを持つ個別の所有エンティティとなるシグナルベースのモデルへの移行が必要であると主張する。これにより、手動で構築された「シグナルグラフ」が作成されるが、これはGPUIの現在の「プレーンな関数」アプローチよりも推論が複雑になる。

この視覚資料は、追跡の精度と実際の実行オーバーヘッドの間のトレードオフを明確にしている。

同様に、Elmアーキテクチャは単一の真実のソースを提供するが、スケールするにつれて管理が困難になる。複雑なアプリケーションでは、単一の値（未読件数など）のロジックがすべてのメッセージバリアントに分散してしまい、中央集中型のシグナル定義よりもメンテナンスが難しくなる可能性がある。