Just the other day on reddit I saw someone asking about efficiently removing an item from an array for the game they’re working on. It became this whole CS debate and then someone asked how big the array is and how often do you remove items. The OP responded that it’s just a list of levels in their game, so not more than 20 items or so and is modified once every 5-10 minutes…

So a day on their game wasted over efficiently removing an item from an array of 20 items every 5-10 minutes.

I used to make 3D engines and asset pipelines professionally. High performance really is critical in both. So, I’d have to check myself frequently:

> If I optimize this, how much time is it going to save the whole world? What will be the sum of time saved by everyone who will ever run this code? Is that less than the time required of me to do the optimization? Then, don’t do it!

That question was relevant quite often.

The big optimizations though really mattered. And, required planning before initial implementation to set the system up to be optimizable.

Really highlights the divide between industry and acedemia.

Reminds me of when another subreddit was mocking some legacy code (I think Motorola? Some mobile device stuff) for using bubble sort. Meanwhile, the sort probably wasnt on more than a fee hundred items and the mobile embedded is constrained for space. Bubble sort is easy to read, write and has O(1) space. Performance isn't a concern at the scale being worked at. We're talking maybe microseconds of difference.

It's not necessarily a bad thing that acedemia focuses on theory. But we keep using school to put a square peg into a round hole and wonder why students are so unprepared for actual production.

It's ultimately the company's fault. If you want certain skills, you need to train for it. Your processes aren't public, so you can't just expect candidates to magically know what matters to their role.

----

now acedemically: the answer is to swap an item to the end and reduce the buffer size. I don't think that's taught in acedemia either, but that's a trick you learn on the job. When and if you do need it.

The full quote is:

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Sometimes the best way to tackle that 3% is upfront when you're deciding on your system architecture.

some games require a certain level of scale and for those games you should optimize in the pre-planning stage.

I think you are missing the point. The larger the scale is, the more things may be optimized and the more you need to be careful to focus on the important "3%". That said, it doesn't hurt to analyse in advance which parts might be critical and steer the architecture based on those observations.

Statistically speaking, 99% of game devs won't ever make a game like that. And if they do, they will probably know ahead of time they are making it.

100% of hobby game devs do it as a hobby. The learning process is the fun part. Which is also why 99% give up on their game when they see more learning potential in another area.