is a process, not a stat, not even a progress bar
please can the Gamers stop saying things have "bad optimization" or whatever. i don't know how to kindly explain to you that the way it sounds lands squarely on a spectrum between clueless and jackass. consider the following:
-
it is a MIRACLE that video games work. like, at all. i make video games and i can hardly believe they exist. and that's before you even get to the graphics!
here, i'll give you all the vertex coordinates of ten thousand objects in 3D space. tell me which ones are touching. you have: 0.005 seconds. good luck
-
making something faster while behaving the same is hard. it is really hard. it is really really fucking hard. it is one of the hardest things. if you're lucky there's some obvious low-hanging fruit that gets you far enough. beyond that it is a niche so specialized that it has no name, performed by 1 witch at your studio that no one's sure they've actually met in person, who disappears for three weeks only to reveal they've improved load times by 9% by forking ext4 to store entries in alphabetical order, whatever the fuck that even means, while the rest of you are desperately scouring stackoverflow for something bozotic like whether double-quotes are "faster than" single-quotes
-
there is no such thing as "fast". there is only "faster", and "fast enough". you don't just keep going until you have Fully Optimized The Code because that is not a real thing. you plunk away at one thing at a time and watch your update and render times drop by microseconds, sometimes unsure whether you've even made a difference because it's drowned out by noise. maybe you made things slightly worse, even. maybe better on one platform but worse on another. cross your fingers i guess. how long until we're supposed to ship, again?
this just really grates at me because like
"it's slow for me" is a factual observation. even "it's slow for everyone" is a factual observation. "it has poor performance" is still a factual observation. "it's fucking unplayable", "runs like ass", sure
but "it's badly optimized" is a value judgement of skilled work that someone did (or lacked time/expertise to do) on code you have never read. it seems to have come out of the same vortex that produces insights like "[game] was made with the unity engine, which is why [non sequitur]" from people who are inexplicably compelled to talk about the nuts and bolts despite having never seen either a nut or bolt themselves
you can just, have opinions on video games. you don't need to try to fake sounding like maybe a programmer
turning a big Dial called "Optimization" and constantly looking back to see how much i can set it to Bad because i hate gamers, especially, man's
if i made a AAA video game i would simply optimize it more. i would optimize it all the way, in fact. simply do maximum optimization. stupid devs, why do they need me to tell them these basic things
i absolutely broadly agree with all the points made here - the outside perception of "lazy devs" is both harmful and inaccurate.
but my full time job is optimization of games for difficult platforms and there is just a baseline educational failure in a lot of cases as to why certain practices will absolutely tank performance. i have seen a surprising number of very mature AAA studios fail to account for a relatively easy to understand principle, once it is known; don't make the computer do more work than it has to.
i see things like repeatedly recalculating expensive transformations each frame, when the thing in question neither moves nor changes each frame, or creating and destroying UI elements instead of making them simply hide and reappear. and these account for a huge bulk of early gains on performance, as long as they are kept in mind from early on in the project.
the industry does not and has never adequately trained people to understand these things intuitively, because our industry has a knowledge sharing problem. many simple, repeatable techniques are hidden from public knowledge under the misguided principle that a studio needs a "secret sauce" to succeed, when really all they are doing is simultaneously reinventing the wheel. seniors burn out, juniors get churned into crunch, and nobody learns the simple techniques that can make their games run smoothly and easily.
overnight someone else also objected that i made optimization sound like something only the Chosen Ones can do. but i think optimization is more a form of bugfixing or auditing, something you do on existing work, whereas "write it so it's not unnecessarily slow in the first place" is a different kind of problem entirely.
and i think it's something that's just kind of hard to learn. it's easy enough to see if code works, because you can just run it and see if it does the thing you wanted. it's harder to see if code "is fast" in some sense, especially when even the "slow" version is so fast it's indistinguishable from noise. a particular pattern may never show up in a profile, but still add up if it's done in multiple places. but it also may not! "you should avoid this, because it might be a problem, later, sometimes, unless it isn't" is somewhat less compelling than "here's how to make your guy fire a gun".
and like, i wouldn't say i actively think about performance when writing code. instead i have a system of internal alarm bells that go off whenever i find myself writing a linear scan, nested loop, basically anything that examines the world state, something complicated per-frame that is likely to have the same result every time, etc. i have a whole series of "what if"s that float to the surface. what if this list is excessively long? can that happen? what if one block in the blockmap accumulates a great many actors? do i want to proactively handle that? what if the player is too far away? what if there is no player? what are my assumptions, and what happens if they are violated?
(sometimes the answer is even "that seems highly unlikely and it's not worth the time to worry about"!)
and that's not easy to pick up. it's not like "a while loop runs until the condition is false" where you read it and now you know it. there's no exhaustive list of all the things you might do that will make the computer spin its wheels unnecessarily, which you can simply memorize and keep in your working memory at all times. you have to pick them up one at a time and develop a sense for the kind of thing to look out for. it comes from experience, but not from writing code — from listening to other people talk about it. and if you don't have that sense yet then i imagine it feels like you're expected to look at every line of code and think about "hmm do i need to do this here", which just sounds incredibly tedious and unrewarding
and even if you're pretty good about it, it's still often counterintuitive, and you might miss something at any time. sure, of course i want to compute this transformation every frame. that's what i do for every other entity, right? do i even know for sure this thing never moves? does it move now, but we changed it later to be static? does it move conditionally?
hell, i've shipped a fucking quadratic draw loop that was obscured by several layers of function calls, thanks to a refactor that wasn't quite finished. i never noticed because my computer is Fast Enough; someone with a slower computer told me about it.
also my experience with bay area tech is that tech companies fight over devs who just got out of college, for some reason. but those are exactly the people who are the least likely to have developed intuitions like this. (ok i guess someone who's only been self-teaching a couple years is less likely but you know.) and it sounds like a similar thing happens in big-name gamedev too. alas
anyway i would say
-
"don't do an expensive thing every frame if you don't need to" isn't optimization so much as Just Programming. it's not a wizard-only skill, but it's hard in its own way, since it's about learning to catch yourself in the process of writing something that (a) feels natural and (b) would work!
-
"find where someone already did an expensive thing every frame when they didn't need to" is optimization and is vastly more annoying. especially if you think you've found such a place and you refactor it and it makes precisely zero difference. that's why optimization is hard: often you are searching a haystack for a strand of hay that looks slower than the others. what does that even mean
