یک نقد فنی بر GPUI این پرسش را محور قرار می‌دهد: وقتی یک مقدار تغییر می‌کند، کدام بخش‌های UI دوباره اجرا می‌شوند؟ نویسنده معتقد است framework باید بداند چه چیزی تغییر کرده و چه بخش‌هایی به آن وابسته‌اند؛ در غیر این صورت، تشخیص این وابستگی‌ها به عهدهٔ برنامه‌نویس می‌افتد.
در GPUI، تغییر state با فراخوانی صریح notify اعلام می‌شود. این اعلان شناسهٔ entity را دارد، اما مشخص نمی‌کند کدام field تغییر کرده یا اصلاً تغییری رخ داده است. طبق توضیح نویسنده، viewهایی که پشت مرز معتبر cache نیستند، دوباره render می‌شوند؛ بنابراین هزینه می‌تواند به ساختار UI وابسته باشد، نه فقط به تغییر واقعی.
در benchmark نویسنده، با ۳۰۰۰ ردیف فعال و یک view دارای cache برای هر ردیف، تغییر یک label حدود ۸٫۴ میلی‌ثانیه طول کشید. با نوشتن ردیف‌ها به‌صورت element معمولی، همان تغییر ۹۲ میلی‌ثانیه زمان برد. او تأکید می‌کند که این نتیجه به معنای کند بودن همهٔ برنامه‌های GPUI نیست، بلکه محدودیتی در مدل state را نشان می‌دهد.
راهکار نگه‌داشتن subtree هر view، از جمله در fork موسوم به gpui-fast، هم از نظر او محدودیت دارد: کوچک‌ترین واحد قابل استفادهٔ مجدد همچنان view است. مستقل‌کردن یک label می‌تواند به entity جداگانه، subscription، نگهداری نسخه‌ای از مقدار و بررسی دستی برابری نیاز داشته باشد. نویسنده این پیچیدگی را با بیان وابستگی از طریق signal مقایسه می‌کند.
نتایج به محل نگهداری state هم وابسته بودند: در آزمایش ۶۰ پنلی، نگهداری ساختار با state مستقل برای هر پنل ۸۳٪ صرفه‌جویی داشت، اما با مدل مشترک همان frame را ۱۱٪ کندتر کرد. نویسنده سازندهٔ ابزار benchmark است، در انتقال Linux rendererِ GPUI به wgpu مشارکت داشته و روی zgui، یک framework مبتنی بر signal، کار می‌کند.
