>What if I wanted to make a program as slow and bloated as possible? >put all state in one place. >no caching. Just as a counterpoint, both as a user and a d

>What if I wanted to make a program as slow and bloated as possible? >put all state in one place. >no caching. Just as a counterpoint, both as a user and a developer I've found the main cause of performance issues and UI bugs come from a combination of distributed state and caching. State being stored as a private member on the widget object itself is arguably more likely to cause a state desync bug or accidental O(N^2) behaviour than everything being global. IMGUI solves this but has only really seen a warm reception amongst the gaming industry (where, incidentally, UIs are always lightning fast despite being traditionally limited by older console/handheld hardware.) Having a cache at the wrong level might reduce some function's execution time from 100us per frame to 10us, but makes it much more likely that the entire app will become unresponsive for 10s while some dumb bit of code rebuilds the whole cache 25,000 times in a row. In a similar vein, I've found issues in multi-threaded apps where some function is sped up from 10ms to 2.5ms by making use of all four cores, but occasionally spins on a mutex, blocking the UI for 250ms if some slow path (usually network/disk IO) is taken. Genuinely, I think the simplest way to make sure a program will have bad performance just requires one step: - Make it difficult for a human programmer to reason intuitively about the performance of the code they write.