His first people is not technically wrong but it is highly misleading. Sure you can't know which bits of a program are going to be slow without measuring, but that doesn't mean you have no clue at all. You can often make a very good guess!
Back then, some devs would do something much more complicated to try to be faster, and often the overall program was worse off.
Nowadays, some devs do something much more complicated, make the program 100x or 1000x slower than the simple obvious way, and think they're doing solid engineering because they're definitely not "prematurely optimizing", they made it so slow and convoluted that you could never accuse them of that!
Another thorn is hiding RPCs, DB queries, and other remote operations behind abstraction boundaries. When people think that .getFooBar() is as cheap as a field access, they have a tendency to not cache+pass forward, but just recompute it, which ends up generating a large amount of redundant queries. That will rack up your 1000x's pretty quick.
I would assume that if you measure enough things and code enough you may start to get a feel for what is going to be expensive and what is not. And then - as before - you can continue to measure and iterate.
(Also, I think you said "first people" when you meant "first point")
Yes but he doesn't say that if you don't measure (which most people won't) then you should still engage your brain.
That's the missing point. Measuring is typically more effort than applying a little brain power and experience. So the choices shouldn't be "measure or nothing", but that's how people always interpret it.
Therefore, given a choice between writing a little code to make the program work or writing a lot of code to maybe make the program work faster... Write a little code and go back and write the longer code iff it will actually help performance as per measurements. You're better off expanding a simple skeleton than moving bones around in an already-complex assembly.
The fact that so many replies are not getting this goes to show how misleading this advice is.
The focus of the advice to me is that software engineers frequently overestimate their ability to predict performance bottlenecks and efficiently allocate time to preemptively address them in the middle of writing the core of the system (for multiple reasons, including both the overall complexity of a complete system and the fact that performance is also a function of the way users interact with the system).
I've built multiple systems where a component we never expected to become a bottleneck becomes the bottleneck because users choose to use the machine in an extremely novel way relative to our intent when we built it. Getting the software in front of users to get signal on the difficult-to-predict user factor was consistently a better use of our time than swapping out a functional n squared algorithm with an also functional n log n algorithm on a piece of the system that no users were operating with yet.
That's why it's bad advice! Perhaps I should rephrase: it's not incorrect advice (to the right target audience), but it most definitely is inadvisable advice.
Who is the audience for the famous "premature optimisation" quote? Maybe originally it was "people who know you shouldn't ignore performance", but it definitely isn't now.
Easily misinterpreted advice is bad advice in my book.
You can make a good guess! Just, measure it to be sure before you start optimizing.
For example preallocating arrays. You don't need a benchmark to tell you it will be faster because it literally can't not be.
Another example from my recent real life: I changed a data structure from a hashmap to an array with integer keys. I didn't profile it because can't not be faster. And I knew it needed to be fast because it is called for every branch in my program.
This assertion is false for JavaScript arrays in the v8 engine in some contexts. Preallocation of a JS array causes the engine to make a heterogeneous array, which is more expensive because it's an object under-the-hood. Allocating the array using repeated `push` calls of homogeneous data lets the engine know it's a homogeneous-type array, which is an "exotic object" that can use more optimal representations under-the-hood. (Faster than both is preallocating a homogeneous array, although that of course requires us to know what kind to preallocate).
This is another example of where premature optimization can lead a developer astray. Abstractions are far too complicated these days, and it's too easy to guess wrong without hard data.
https://dev.to/henryjw/populating-a-pre-allocated-array-slow...
Forget everything you have learned about the famous BigO analysis for 99% of the cases because it assumes a computing model that is no where near what we have today. It was close in the 80-s but now it's totally wrong.
the most glaring example i can offer is that nowdays for example a datastructure based on a linked list will almost always be slower than one based on arrays even though the BigO analyses says otherwise.
CPU cache plays a much bigger role and it pays more to chase a consistent cache access rather than jumping all over through pointers and thrasshing the cache.
likewise most algorithms would be faster looping through all array items rather than for example using a set or hashMap when number of items is small (and by small we are still talking about hundreds of elements, the exact number when one datastructure becomes better than the other will depend on many factors.
that's why, don't assume but measure, it's the best advice there is.
Well, yes I can because I know everything you just said already...
> a datastructure based on a linked list will almost always be slower than one based on arrays even though the BigO analyses says otherwise.
Cache locality is one reason that linked lists are usually slower, but I think you've got a bit mixed up because the big O analysis also says they'll be slower (in most common cases).
> that's why, don't assume but measure, it's the best advice there is.
You missed my point (thus proving why this is misleading advice!)