It’s kind of funny how eagerly we programmers criticize “premature optimization”, when often optimization is not premature at all but truly necessary. A related problem is that programmers often have top-of-the-line gear, so code that works acceptably well on their equipment is hideously slow when running on normal people’s machines. When I was managing my team, I would encourage people to develop on out-of-date devices (or at least test their code out on them once in a while).
Premature optimisation often makes things slower rather than faster. E.g. if something’s written to have the theoretical optimal Big O complexity class, that might only break even around a million elements, and be significantly slower for a hundred elements where everything fits in L1 and the simplest implemention possible is fine. If you don’t know the kind of situations the implementation will be used in yet, you can’t know whether the optimisation is really an optimisation. If it’s only used a few times on a few elements, then it doesn’t matter either way, but if it’s used loads but only ever on a small dataset, it can make things much worse.
Also, it’s common that the things that end up being slow in software are things the developer didn’t expect to be slow (otherwise they’d have been careful to avoid them). Premature optimisation will only ever affect the things a developer expects to be slow.
Optomisation often has a cost, weather it’s code complexity, maintenance or even just salary. So it has to be worth it, and there are many areas where it isn’t enough unfortunately.
It’s kind of funny how eagerly we programmers criticize “premature optimization”, when often optimization is not premature at all but truly necessary. A related problem is that programmers often have top-of-the-line gear, so code that works acceptably well on their equipment is hideously slow when running on normal people’s machines. When I was managing my team, I would encourage people to develop on out-of-date devices (or at least test their code out on them once in a while).
Premature optimisation often makes things slower rather than faster. E.g. if something’s written to have the theoretical optimal Big O complexity class, that might only break even around a million elements, and be significantly slower for a hundred elements where everything fits in L1 and the simplest implemention possible is fine. If you don’t know the kind of situations the implementation will be used in yet, you can’t know whether the optimisation is really an optimisation. If it’s only used a few times on a few elements, then it doesn’t matter either way, but if it’s used loads but only ever on a small dataset, it can make things much worse.
Also, it’s common that the things that end up being slow in software are things the developer didn’t expect to be slow (otherwise they’d have been careful to avoid them). Premature optimisation will only ever affect the things a developer expects to be slow.
Optomisation often has a cost, weather it’s code complexity, maintenance or even just salary. So it has to be worth it, and there are many areas where it isn’t enough unfortunately.
And that lazy mentality just passes the cost to the consumer.
Your spelling is terrible
Oops, forgot the AI step