I had a computer science exam some ~20 years ago where we were writing (like, with pencil and paper!) C code. I had been programming in C since middle school while most of the class was learning C for the first time.
I wrote a very sexy copy loop with pointer arithmetic and a comment to the side explaining why, and pointing to a particular pre-increment in the copy as an optimization.
The TA took points off and wrote that micro optimizations are useless and, verbatim "premature optimization is the root of all evil."
I know exactly which TA wrote it, and he was, and I'm sure still is, an effeminate, arrogant, mincing prick. He just did not understand the code. Luckily I appealed to the professor and he reversed it. Yes, I'm still salty about this.
Writing efficient code isn't premature optimization. "Optimization", in the turn of phrase's context specifically, is supposed to mean corner-cutting and hacky workarounds to save a step or two.
Writing good code in the first place REMOVES the need for optimization.
Writing good code in the first place REMOVES the need for optimization.
No, those are different. Look up the famous Quake 3 root optimisation, technically it's immensely faster, but not considered good code, because it's full of "magic numbers" and incredibly hard to understand while the code nor the comments don't provide any info on what's it's doing at all. It generally take a 15mn video to understand those 3 last lines.
This is actually a perfect example of premature optimization.
They just assumed that mechanical hard drives would be such a huge performance hit that they apparently reorganized their data to duplicate it so that (presumably; I can only speculate because they don't actually specify and I can't conceive any other possible reason to do this) would minimize seek times.
They can't even guarantee it had any real positive effect. It's not like Helldivers is telling the HDD precisely where to write things. These files-in-triplicate could all be right next to each other, while big individual files are fragmented and scattered all over the disk.
100% this. Data duplication made perfect sense when you're reading off optical media where you control where the tracks are. You don't want the read head having to index back and forth constantly. You want similarly accessed data in nearby rings.
On a PC, the dev doesn't really have control over where the files are written in the first place. Now, what I could believe is that every subsequent expansion duplicated assets from the previous releases, because they knew that updating the originals would invite fragmentation.
My money is on them not being confident that they weren't breaking old content so they just made the new content effectively standalone. Probably punted on regression testing too.
It could just be sheer lazyness. Just duplicating assets because it's easier to copy-past entire structures than it is to properly link them one at a time.
There's some truth to it. The last time I had to genuinely optimize something for performance it resulted in some truly ugly things going on under the hood that made the code way less coherent and maintainable. Some basic optimization should be baked in as part of best practices, but doing some of the darker optimization wizardry should indeed be avoided until that evil becomes necessary.
Sure, but the cases where you need the crazy things for optimization are few are far between. So much of the time it's just using the correct algorithm instead of brute forcing everything. Casey Muratori puts it far better than I in this interview:
It's just crazy how people refuse to even consider optimization, especially in AAA game dev. If every developer could be like Wube (factorio) and Coffee Stain (Satisfactory, which is in Unreal 5, and shows how every other game in Unreal 5 is deliberately deoptimised), gaming in general would be better.
Oh I agree that if we had developers who actually used optimization instead of farting out whatever would compile then the industry would be in a much better place. If you demand that level of competency in the technical aspect you necessarily create a culture where you start selecting for competency across the board instead of all the ideologically based hiring that happens now. There's the best games were made by a bunch of White and/or Japanese autists while the danger hairs have created nothing of value during their entire tenure in the industry.
That would take a bit of time to learn how things like hashmaps work though. Why do that when you could just solve every problem by iterating through arrays instead?
"Premature optimization is the root of all evil"
That phrase has done more damage to the software industry than even Indians. And when you combine it with Indians it is even worse.
I had a computer science exam some ~20 years ago where we were writing (like, with pencil and paper!) C code. I had been programming in C since middle school while most of the class was learning C for the first time.
I wrote a very sexy copy loop with pointer arithmetic and a comment to the side explaining why, and pointing to a particular pre-increment in the copy as an optimization.
The TA took points off and wrote that micro optimizations are useless and, verbatim "premature optimization is the root of all evil."
I know exactly which TA wrote it, and he was, and I'm sure still is, an effeminate, arrogant, mincing prick. He just did not understand the code. Luckily I appealed to the professor and he reversed it. Yes, I'm still salty about this.
The prick works at Facebook today.
Writing efficient code isn't premature optimization. "Optimization", in the turn of phrase's context specifically, is supposed to mean corner-cutting and hacky workarounds to save a step or two.
Writing good code in the first place REMOVES the need for optimization.
No, those are different. Look up the famous Quake 3 root optimisation, technically it's immensely faster, but not considered good code, because it's full of "magic numbers" and incredibly hard to understand while the code nor the comments don't provide any info on what's it's doing at all. It generally take a 15mn video to understand those 3 last lines.
I watched a video about that a couple of years ago. Great stuff, highly recommended.
This is actually a perfect example of premature optimization.
They just assumed that mechanical hard drives would be such a huge performance hit that they apparently reorganized their data to duplicate it so that (presumably; I can only speculate because they don't actually specify and I can't conceive any other possible reason to do this) would minimize seek times.
Fucking insane.
And, again, they SHIPPED this.
They can't even guarantee it had any real positive effect. It's not like Helldivers is telling the HDD precisely where to write things. These files-in-triplicate could all be right next to each other, while big individual files are fragmented and scattered all over the disk.
100% this. Data duplication made perfect sense when you're reading off optical media where you control where the tracks are. You don't want the read head having to index back and forth constantly. You want similarly accessed data in nearby rings.
On a PC, the dev doesn't really have control over where the files are written in the first place. Now, what I could believe is that every subsequent expansion duplicated assets from the previous releases, because they knew that updating the originals would invite fragmentation.
My money is on them not being confident that they weren't breaking old content so they just made the new content effectively standalone. Probably punted on regression testing too.
It could just be sheer lazyness. Just duplicating assets because it's easier to copy-past entire structures than it is to properly link them one at a time.
^ This guy has defragged a hard drive before.
And it makes no sense on its face. If you test at the unit level, why wouldn't you optimize at the unit level too?
There's some truth to it. The last time I had to genuinely optimize something for performance it resulted in some truly ugly things going on under the hood that made the code way less coherent and maintainable. Some basic optimization should be baked in as part of best practices, but doing some of the darker optimization wizardry should indeed be avoided until that evil becomes necessary.
Sure, but the cases where you need the crazy things for optimization are few are far between. So much of the time it's just using the correct algorithm instead of brute forcing everything. Casey Muratori puts it far better than I in this interview:
https://youtu.be/apREl0KmTdQ?t=242
It's just crazy how people refuse to even consider optimization, especially in AAA game dev. If every developer could be like Wube (factorio) and Coffee Stain (Satisfactory, which is in Unreal 5, and shows how every other game in Unreal 5 is deliberately deoptimised), gaming in general would be better.
Oh I agree that if we had developers who actually used optimization instead of farting out whatever would compile then the industry would be in a much better place. If you demand that level of competency in the technical aspect you necessarily create a culture where you start selecting for competency across the board instead of all the ideologically based hiring that happens now. There's the best games were made by a bunch of White and/or Japanese autists while the danger hairs have created nothing of value during their entire tenure in the industry.
That would take a bit of time to learn how things like hashmaps work though. Why do that when you could just solve every problem by iterating through arrays instead?
They'd accidentally end up getting there simply because they'd choke once they started trying to iterate through multi-dimensional arrays.
There's a red pill for that.