"I’ve noticed when I think about performance nowadays that I think in terms of two different aesthetics. One aesthetic, which I’ll call Never Miss a Frame, comes from the world of game development and is focused on writing code that has good worst case performance by making good use of the hardware. The other aesthetic, which I’ll call Do Almost Nothing comes from a more academic world and is focused on algorithmically minimizing the work that needs to be done to the extent that there’s barely any work left, paying attention to the performance at all scales." http://thume.ca/2019/07/27/two-performance-aesthetics

Robust-first parallels: Do Almost Nothing -> Correctness & Efficiency Only (CEO); Never Miss a Frame -> A Cycle Saved is a Cycle Wasted.

@Kartik Agaram This article is wonderful. I've been wrestling with both aesthetics in the design of Hest, since there are several features that need the never-miss-a-frame smoothness of a video game (eg: panning and zooming and playing in the editor), and some that need the don't-do-work for battery efficiency (eg: shut down the never-miss-a-frame run loops if we can tell that they aren't going to produce any changes), and some that need a different kind of don't-do-work for the sake of fast execution (eg: running end user code as fast as possible, but in a way that is still perfectly deterministic and behaves identically to the slow-motion debug execution). It's been really hard to balance these aesthetics, since these various features that need different aesthetics all touch the same data, so the possibility space for how I can represent that data is wildly constrained. Can't use flat lists and iterate over everything every frame (great for frame rate, terrible for full-speed execution), can't store relationships between entities (great for full-speed, terrible for worst-case), can't use partial application, can't use per-entity caching...