Performance optimization is hard because it's fundamentally a brute-force task • Hacker News Board

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

#151

Post by saagarjha » Thu, May 01, 2025, 11:01 AM UTC

Sesse__ wrote: post #132

saagarjha wrote: post #117

Earlier quoted context omitted.

I’m honestly curious why the defaults are the way they are. I have basically never found them to be what I want. Surely the perf people aren’t doing something completely different than I am?

I almost never find graph usage useful, TBH (and flamegraphs are worse than useless). And perf's support for stack traces is always wonky _somehow_, so it's not easy to find good defaults for the cases where I need them (I tend to switch between fp, lbr and dwarf depending on a whole lot of factors).

To be honest I don't like Linux profiling tools at all. Clearly the people working on them have a very different set of problems than I do

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

#152

Post by cogman10 » Thu, May 01, 2025, 4:41 PM UTC

YZF wrote: post #147

9rx wrote: post #141

Earlier quoted context omitted.

Beware of microbenchmarks, but at least on my machine under the specific circumstances I ran it under, the double loop algorithm is about two times faster than the hash map algorithm while n < 100. That might not mean much if you spend your days working with large datasets, but in my day-to-day datasets with 100 entires or less is the norm. Readability is subjective, but at least from a performance perspective it is…

We're not really benchmarking here. The author of the code does need to understand the size of the data they're operating on etc. I also didn't critique the hashmap version. Using hashmaps [for] everything is also "lazy". 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.…

> I mean at least cut the iterations in half by not iterating over the entire range in the inner loop!

The reason I wrote it that way is because the actual common way I find this is in Java where the team wants to use the `stream` api.

IE

    items.stream()
      .filter((item)->items.stream()
        .filter((item2)->item2 != item)
        .findAny((item2)->Object.equals(item.foo, item2.foo)).isPresent())
      .toList();

That's not really super readable or universalizable to other languages.

Even more commonly, instead of doing the `findAny` I often see the trip up being someone doing a `contains` or other O(n) operations on `List` objects inside iterations of that list.

It's this sort of fluent/functional style of programming that often seems to get tripped up on doing n^2 (or more) algorithms.

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

#153

Post by hinkley » Thu, May 01, 2025, 7:33 PM UTC

hinkley wrote: post #60

AtNightWeCode wrote: post #51

Earlier quoted context omitted.

Agree with this. But not what I concluded from OP. Architectural decisions from the start is where most optimizations should happen. I remember from school some kids that did this super optimized loop and the teacher said. Do you really have to do that same calculation on every iteration? But, in the real world. Code bases are massive. And it is hard to predict when worlds collide. Most things does not matter until t…

Measuring is also useless once someone has introduced bottom up caching. There’s so much noise at that point that even people who would usually catch problems start to miss them. There’s usual response to this is, “well you can turn caching off to do profiling” but that’s incorrect because once people know they can get a value from the cache they stop passing it on the stack. So your function that calls A() three tim…

And I forgot the worst part which is that most of these workflows assume that A() will return the same answer for the duration of the interaction and that’s just not true. Passing value objects on the stack guarantees snapshotting. For the duration of the call sequence, all of the code will see the same A. Not so with the cache.

You make still run into problems where you expect A and B to have a relationship between them that doesn’t hold if there’s a gap between looking them up, but it’s often less likely or severe than if for instance half a page has the data in state S and half of it is in state T.