The encapsulation-performance tradeoff 0 ▲ Nate Meyvis 48 minutes ago · Tech · hide · 0 comments Maintaining proper encapsulation is great, but can make it harder (or impossible) to optimize performance. Here are some examples: A function or service has the ostensible job of returning all items that satisfy criterion X, but all its callers (or all its current callers) only need some subset of those items.1 Because it's faster to retrieve that subset, and because sending back the smaller payload also saves some resources, it's tempting to just make the function a subset-retrieving function, even if its name or documentation says otherwise. You must therefore choose between two implementations, one of which saves resources and the other of which is more intelligible, extensible, and nameable. The latter preserves encapsulation much better.2 There is a genre of function that works toward some goal, but in a short-circuit-friendly way. Talk to your preferred LLM about "anytime algorithms" or why engines have separate functions for any-hit and closest-hit algorithms in ray tracing.… No comments yet. Log in to reply on the Fediverse. Comments will appear here.