> What game developers are good at is not making slow programs.
That isn't true. Many games, even really popular/enjoyable games, have really poor performance for what they do. And much of the performance that does exist is thanks to the people who work on the engine and not the game itself.
I'm not sure the average game-dev is any better at writing performant software than the average non-game-dev.
I do find it amazing how much leeway other industries have when it comes to performance compared to my native industry of gamedev. I'm constantly thinking about how to structure things to avoid dynamic allocations at all costs, reduce memory footprints, reduce branches, on top of balancing usual concerns like readability, extensibility, etc. This often means forgoing abstractions as often as is reasonable.
My coworker, bless him, who comes from a background in the financial industry once added a feature that involved making copies of 5 vectors of strings. Both the vectors and their strings were regenerated every single tick from c strings that permanently resided in memory, by way of multiple concatenations for each string. Profiling informed me we were now making some hundreds upon hundreds (sometimes thousands) of (re)allocations every 16.7ms. I diplomatically pointed out the wastefulness and he (partially) fixed the issue by changing 2/5 of the getter functions to return a reference. I could tell he was quite annoyed with me, and didn't really understand the issue. It's just allocating memory, how bad could that be?
That isn't true. Many games, even really popular/enjoyable games, have really poor performance for what they do. And much of the performance that does exist is thanks to the people who work on the engine and not the game itself.
I'm not sure the average game-dev is any better at writing performant software than the average non-game-dev.