# A Pragmatic Game Programmer’s Approach to Optimization

Prioritize delivery and maintainability, understand client and server bottlenecks, and optimize around a measured workload.

> I recently interviewed several backend programmers and asked about optimization. Many struggled to give a good answer.

First, what makes a programmer pragmatic? On a game project, schedule matters enormously. A pragmatic programmer should solve problems quickly and deliver stable code promptly, while keeping it maintainable enough to accommodate changing design requirements.

One interviewee described optimizing an inventory system. Items had originally been represented as dictionaries, such as `{name:"item1", lv:1, num:99}`. To save space, the developer changed the representation to an array: `["item1", 1, 99]`. This removed redundant keys, with an API wrapped around the representation to access its fields.

But was that optimization necessary? It might have halved the inventory system's memory use. Yet how much of the player's total data did inventory occupy? If it accounted for only 2% of memory, reducing it to 1% saved just one percentage point overall. In exchange, the code became harder to maintain and the project slowed down. That is a poor trade.

Here are a few of my views on optimization:

1. **During game development, optimization has the lowest priority.** We should not proactively optimize everything. Development speed and maintainability come first, unless a particular feature has hit a bottleneck.

2. **Understand the different bottlenecks on clients and servers.**

   In my experience, clients are often constrained by memory. They cache not only logical data but also images, models, fonts, and other assets, while having limited process memory available. Client-side optimization therefore often trades time for space: load data and assets dynamically when needed.

   Servers are often constrained by CPU. They serve thousands of clients at once. In frameworks such as Skynet, saturating a single CPU core can make some functionality noticeably stall. On the server, I therefore tend to trade space for time: prepare and cache data at startup. That can simplify the logic as well as reduce runtime computation.

3. **Define the workload before optimizing.** Optimization has no natural endpoint. Establish the data scale and call frequency first: the maximum players per server, scene size, maximum objects, and how often players act. Optimize around those constraints rather than creating work with little payoff. If a server holds only 1,000 players and a leaderboard needs only the top 100, insisting on a red-black tree may be overkill. I have made that mistake myself, even modifying the tree algorithm to support rankings.

4. **Code structure deserves optimization too.** I prefer to refactor early, making interfaces clear and easy to use. That can delay the arrival of a tangled codebase—even if I suspect every sufficiently long-lived project eventually becomes one.

Know when to stop. Avoid an optimization when it is not needed. Most organizations are held together more loosely than we like to admit, and a one-percent performance gain is unlikely to earn you a special reward.