ehab.dev

optimization · performance

Why following real-life concepts in code can hurt performance

obvious systems planning techniques often limit how efficient the code can be

8 min read

the idea:

We tend to approach code with the same logic we use to navigate everyday life. This intuition works about 95% of the time. but that remaining 5% is often responsible for most of our game-thread performance problems. Computers aren’t bound by real-world logic. relying on it anyway is what limits how optimized a system can become. That’s not a mistake so much as a blind spot - and learning to see past it pays off in the long run.

what might this look like in practice?

  1. Treating every actor of the same class identically. same priority, same behavior regardless of state, distance, or net mode.
  2. Running identical per-frame loops for every actor just to filter or prepare data that only matters for one decision branch.
  3. Narrow-scope system planning. functions that run their full sequence on every call, even though 80% of those calls only need 20% of that code.
  4. Ticking every system at the same fixed rate to keep the code flow simple, even when over half that data hasn’t changed since the last update.
  5. Designing systems as multi-instance objects, each isolated and self-contained, so every instance ends up redoing the same work to prepare identical data.

what’s the alternative?

In order to achieve what I like to call operational efficiency we need to broaden the architectural scope, stepping back far enough to see how these systems actually interact within the larger structure, not just how each one behaves in isolation.

  • Split large systems into subsystems, and run each one only as often as its data is actually expected to change.
  • Scale update frequency by distance, type, and net mode - instead of running every instance at full behavior, all the time.
  • When multiple instances need the same gameplay data, don’t make each one fetch it independently. Run a single loop in a shared, high-level class - like the GameState or GameMode - and let every instance simply read from it, where the data model allows.

conclusion

Our narrow-scope, linear thinking is neither a mistake nor a weakness. But the systems we build aren’t bound by it. The world our code exists in doesn’t care how we structure each system or function. it charges us for its processing. one tick at a time.