Hacker News Reader

Comment by theonemind | Hacker News Reader

I don't know. In general, it's advisable to write your code first largely ignoring performance considerations, just do the simplest/most readable thing, then profile it and see where it bottlenecks.

So, that's the best general wisdom I know. Don't even bother trying to guess where you'll have performance problems. Profile it.

View on HN

This just defers the optimization process by one step. It's hard to improve something without measuring it first, but either you know where your inner loop is or the profiler tells you. Now you've still got to improve that bottleneck somehow and take into account all those complicating factors.

I've seen very unexpected results doing this. In one case, I put the inner loop in a separate function to enable swapping implementations and make it simpler to time. Surprisingly, the overall program ran faster without any other changes. Just pulling the inner loop into a function of its own sped things up.

My best guess was that the compiler was willing to put more effort into optimization on the smaller function. This contradicts common wisdom about function call overhead, and it also shows another level of complexity in the problem: Some compiler optimizations are exponential in their cost, so they punt if you put too much of your code in one block or function.

Also note that I wasn't able to prove this is what happened. It's just my best guess based on what I was able to see and infer.

I prefer to keep the approximate performance of my code in my head as I write it to ensure that I'm using appropriate data structures and abstractions since it's often costly to change these things after your profile.

Reply on news.ycombinator.com