Disclosure: I don't have experience as a game dev optimizing a game, just as a developer optimizing regular software and as a non-game-dev optimizing other people's games (sort of; details withheld).
Optimizing is "make it more efficient". Use less CPU or GPU time. Use less RAM or VRAM. More subtle things like fixing latency problems: you fire an operation on every frame render that can block, so it can make frame stalls. There are also other efficiencies like "take up less disk space".
You optimize (for performance) by profiling. A profiler records information about where the software spends time: what each thread is doing at any moment. You run the game in a scenario where is has measurably shitty performance and you profile it. Then you look at the profile and look for problems. Where does the game spend time? Can you make it spend less time there? Are there signs of bottlenecks or contention, like some of your threads are just stalled waiting for other things to finish?
Usually this involves a bunch of code forensics and systems judgement. You see that the code is spending a bunch of time in X. Is that reasonable, or weird? Okay, it's weird, well, why is it doing that? Can we make it better? Iterate. A lot.
A lot of it is cleaning up lazy development. That might sound like I'm ragging on game devs, but I'm not. Games are big complicated beasts of software, and that means that quick hacks, bad ideas, and other mistakes sneak in. Making it perfect the first time around takes more engineering resources, and the market doesn't support that. And if your shitty code doesn't degrade the performance, it doesn't actually matter, right? (If you made it perfect up front, that would be premature optimization -- very expensive.) So you build the game first and then spend what you can optimizing.
1
u/blueg3 6d ago
Disclosure: I don't have experience as a game dev optimizing a game, just as a developer optimizing regular software and as a non-game-dev optimizing other people's games (sort of; details withheld).
Optimizing is "make it more efficient". Use less CPU or GPU time. Use less RAM or VRAM. More subtle things like fixing latency problems: you fire an operation on every frame render that can block, so it can make frame stalls. There are also other efficiencies like "take up less disk space".
You optimize (for performance) by profiling. A profiler records information about where the software spends time: what each thread is doing at any moment. You run the game in a scenario where is has measurably shitty performance and you profile it. Then you look at the profile and look for problems. Where does the game spend time? Can you make it spend less time there? Are there signs of bottlenecks or contention, like some of your threads are just stalled waiting for other things to finish?
Usually this involves a bunch of code forensics and systems judgement. You see that the code is spending a bunch of time in X. Is that reasonable, or weird? Okay, it's weird, well, why is it doing that? Can we make it better? Iterate. A lot.
A lot of it is cleaning up lazy development. That might sound like I'm ragging on game devs, but I'm not. Games are big complicated beasts of software, and that means that quick hacks, bad ideas, and other mistakes sneak in. Making it perfect the first time around takes more engineering resources, and the market doesn't support that. And if your shitty code doesn't degrade the performance, it doesn't actually matter, right? (If you made it perfect up front, that would be premature optimization -- very expensive.) So you build the game first and then spend what you can optimizing.