> Firstly you're almost always wrong about what you think will be slow. Add to that it's rare you actually know how a programm will really be used.
If you don't have a good idea of what is likely to be slow, we have a problem. It's usually I/O, especially synchronous network I/O.
During initial development, maybe you don't know how a program will be used, but maintenance is usually a bigger phase than initial development, so you should have some idea of how things are used.
> Secondly most programs never get stressed so it was a complete waste of time.
What are you working on? Everything I've worked on that has users could go faster. It doesn't take that much complexity to get something that takes 100 ms; and making that take 50 ms instead is an easily perceptible difference.
> So all that knowledge, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.
You could fill volumes about the cock ups and bad code caused by completely garbage performance because people didn't stop to think about how to do things right. Simple things like reducing the number of round trips to the database, or avoiding calculations until you know you need them could be called premature optimizations or just doing the job right. Having knowledge of algorithms (and knowing what algorithms are likely to underly the abstraction layers you're using) helps you avoid writing code that will blow up.
Reducing the round trips to the DB or doing calculations when you need them need no knowledge AT ALL of algos.
Saying it's "I/O" is so abstract and ultimately useless. A simple SQL query could hold a dark secret of a missing index on a table with a billion rows. Yes, that's technically I/O, but for today's programming that's so obtusely abstract it's pointless calling it that. It's a couple of lines of code that all the algo knowledge in the world won't have stopped the problem happening.
It's simply common sense. This is what we're trying to tell you. This is what we're trying to explain to you. Performance problems are almost always unintended consequences rather than "I'll suck it and see". Knowing how to implement the sort yourself won't save you, you have to spot the problem first, which is the hard part.
Basic multiplication is not algos. Knowing that a 100 loops of a thousand loops of a 1ms method is bad doesn't require magical knowledge. Algorithms was always a smoke and mirror trick, the ones you need are usually already in your language written much better than you could and the rest simply hides the truth that performance is mainly down to unexpected I/O bottlenecks usually buried under many layers of abstraction (SQL) or the occasional loop within a loop hidden in a long call stack.
If you don't have a good idea of what is likely to be slow, we have a problem. It's usually I/O, especially synchronous network I/O.
During initial development, maybe you don't know how a program will be used, but maintenance is usually a bigger phase than initial development, so you should have some idea of how things are used.
> Secondly most programs never get stressed so it was a complete waste of time.
What are you working on? Everything I've worked on that has users could go faster. It doesn't take that much complexity to get something that takes 100 ms; and making that take 50 ms instead is an easily perceptible difference.
> So all that knowledge, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.
You could fill volumes about the cock ups and bad code caused by completely garbage performance because people didn't stop to think about how to do things right. Simple things like reducing the number of round trips to the database, or avoiding calculations until you know you need them could be called premature optimizations or just doing the job right. Having knowledge of algorithms (and knowing what algorithms are likely to underly the abstraction layers you're using) helps you avoid writing code that will blow up.