Librarianon

Also yes to the witch. Everyone's been fighting to pare cycles from the inner game loop for three weeks and they turn up in awful shape at standup one morning having not slept in four days. The new routine is a bunch of raw opcodes in a byte array that, insanely, means the same thing in armhf as it does in x64. It is 50% faster but no one understands how it works, them included. The CR has the original assembly but it doesn't assemble to the same set of opcodes in from either the ARM or Intel assembly source. It passed all the tests however. They do not turn up at any more team meetings. A month after launch you find out they moved to Alaska.

you don't just keep going until you have Fully Optimized The Code because that is not a real thing.

Wanted to add to this, because optimizing graphics is currently my job, and explaining things like this to my coworkers is therefore also my job.

Doing an optimization is several kinds of hard. Doing a "full optimization" is several kinds of impossible, coupled with several kinds of not well defined.

I can make benchmarks that try to represent real-world stress cases such that "code that performs well on these benchmarks will seem fast to users". Inevitably some of the assumptions I made will turn out to have been wrong. I'll have missed some rare but important real-world case and have to make updates to the benchmarks.

But let's suppose my assumptions are solid, and that I can use the benchmarks as ground truth. There's still a sense in which "optimization" is not well defined. Doing well on one test-case in one execution environment doesn't guarantee doing well on all of them. There's room in the design space to make tradeoffs, like "what if I did some extra computation to prune some potentially unneeded branches? It would make some cases faster and others slower". If I want some way to compare apples and oranges, I could make up a composite score that flattens all the results into one metric. Again, I'd be making assumptions that are definitely arbitrary and probably wrong.

But let's suppose that I've made the "right" assumptions (whatever that means). There's now some sense in which code could be said to be "optimal" with respect to that metric. Once I've fixed a scoring system, there exists some implementation out there that gets the best score. Of course, I still don't know what the best score is, and finding out is an undecidable problem.

the irony of going on reddit to complain about something that's making your computer to a large amount of unnecessary work to accomplish a relatively simple task

This reminds me of the old days when I had to regularly engage with programmers who had big-O Opinions on the relative "efficiency" of different programming languages. Because yes, the problem with your code is definitely that you're running on top of a virtual machine and not the fact that your data is stored with no plan of how to connect related elements, and you should definitely rewrite the whole thing in assembly language to trip half a percent off the runtime, assuming that it doesn't produce so much code that you have more cache misses...

This is a fair criticism and I will be altering my language accordingly.

Except with one exception: "Final Fantasy XIV 1.0 was badly optimized" is a factual statement because of shit like the flowerpot that had more polygons than a player character.

knowing gamers, i would bet money that someone somewhere up the chain in the game of idiot telephone, someone vaguely knew about the -O flags on C compilers and still literally thinks that optimization is just "run it on the biggest -O".