Performance optimization is hard because it's fundamentally a brute-force task

Not really. You're just exploring an unknown frontier. Once the frontier is known and you actually understand what you are trying to solve you're still going to put in the right algorithm.

I mean, you might not if you're vibe coding, which I guess is apparently a thing somehow, but I'm assuming we're talking about actual engineering here, not speaking the sordid tales of cowboys. The "premature optimization" line was definitely not directed at those who think code is a feeling.

When the frontier is unknown, whatever algorithm gets something operating as soon as possible is the right one. The given example may be so contrived that the hash map would be what you see as the quickest and dirtiest solution anyway, but with a little more complexity loops do tend to be easier to reason about on a first-pass basis.

> Now all the sudden this method becomes a fault in the application you developed that needs to be rewritten.

In the same way that finding out that a blue button doesn't resonate with users, requiring you to rewrite your application to make the button green. Such is the life of building software. But that's why engineers get paid the big bucks – nobody else is stupid enough to do it.

> A lot of the code I've fixed has been due to this.

You're not really fixing it, you're updating it to reflect the information you gleaned during the exploratory phase. I mean, unless you're coding on vibes or something, but, again, assuming actual engineering is taking place here. Nobody should be coding non-prototypes by the guide of their feelings.

Not so much as collateral damage when different optimizations negatively interact though.

Even when optimization is not further possible[0] a careful avoidance of distinct pessimizations themselves can lead toward the same kind of beneficial outcomes.

[0] Or at the other extreme, not the least bit possible.

Good code should follow something along these lines:

- A reasonable understanding of what needs to happen. What are the requirements. Including data set sizes. Including how "hot" this code path is.

- A reasonable pick of the algorithm to perform what needs to happen.

Sure. O(N^2) for very small data sets could outperform an O(NlogN) or O(N). The conflation of big oh notation with actual performance is just another form of sloppiness as is picking a bad algorithm. In both cases it reflects a lack of understanding of how computers work and how to do things efficiently.

Let's look at what we're trying to do here. We want to find all values that occur more than once in a vector. Using a hash map means you have to:

- Create this data structure on the fly.

- Hash the values.

- Do the insertions/lookup.

You should consider the size of your dataset, you should consider locality/caches etc.

100 entries squared is 10k though. If this is part of a critical code path, let's say your frontend code does this for every DOM element or every notification it needs to process this can end up the bulk of CPU usage. This sort of stuff is why I've seen applications cause the fans to go on or the browser to crash. I would say bad O(N^2) algorithms for large Ns are pretty common.

I would be surprised if e.g. a C++ implementation of the hash version doesn't win over the double loop for data sets of 100. But maybe that's borderline. For a dataset of 1000 there's no way the double loop is winning.

Other alternatives might be something like an efficient small bloom filter that can be stored in a register, sorting the array. I mean at least cut the iterations in half by not iterating over the entire range in the inner loop!

Then you won't have the trouble with:

  if (item != item2 && item.foo == item2.foo) {

For this we need programmable languages in which users can code their own optimization cases.

There is such a thing as "I would like a certain optimization, that should not be upstreamed into the compiler".

That's exactly what's in this article.

The construct:

  HashSet::from([a, b]).contains(&c);