Hacker News Reader

Comment by marta_morena_25 | Hacker News Reader

You really don't need to read assembly for any but the most rare cases. What you need is a profiler to give you the hotspots and you need to stop prematurely optimizing on a line-by-line basis. Just stop it. Optimize O(n) performance (but also don't go wild, unless there is a business reason), keep your fingers off micro-optimizations, unless so indicated by the profiler and only if there is a business reason as well...

View on HN

Totally agreed. Getting comfortable with a profiler is a superpower.

FWIW, this is also one of Rob Pike's rules of programming:

> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.

It's implicit, but the "proven" part implies use of a profiler.

This is a matter of experience. If I have a tight loop looping millions of times but I have a heap allocation inside, I can be 99% sure this would be slow, without looking at the profiler and if there is an easy way to avoid it without obfuscating the code (e.g simply taking it out of the loop, or using the stack instead of the heap), I'd just do it. Profiling is a waste of time in such cases.

Also, bottlenecks happen in surprising places, and allowing slow/bad code just because the profiler doesn't scream about it on the development machine is a recipe for surprising performance issues in the future. The slow code might become a problem when a user has slightly different task for the program.

I agree with you, too, that experience helps.

But I think the aphorism covers the case you’re describing too.

It’s possible that your loop is slow, but if you’re working on a program of sufficient size and complexity, you simply won’t know if it’s the bottleneck without using a profiler.

The purpose of the statement is to save you the trouble of 10xing performance of a function, so that it takes .1% of all execution time, instead of 1%. Do sufficiently complex programs, and without a profiler, you won’t really know if a loop is taking 1%, 10%, or 80%.

While I agree with you, I also remember a presentation which showed that there was big variability in performance caused by minor change in the environment: just using a different username could lead to very different performance.

And there are also the 'thousand cuts' issues for which profilers are "useless"..

Never, ever, "help" the compiler.

Counterargument that you should focus on letting the compiler help you which is just a redirected way of "helping" the compiler.

Types are a really good example of where you want to help the compiler. Type signatures let you define how the type can be used. By adding as much information about how the type should be constrained, you can help the compiler prevent you or someone else from doing something stupid and on occasion, you can earn some optimisations in the process.

Reply on news.ycombinator.com