Live data from Hacker News

Ask HN: What are the 20% tips that will get my code to performance 80% faster?

news.ycombinator.com

41–50 of 69 posts

Re: Ask HN: What are the 20% tips that will get my code to performance 80% faster?

#41
post #20

Stop worrying about how well your code performs and focus on more important things. Seriously. I'm not saying that code performance isn't important; of course it is. It's just that if you're already fairly competent, then code performance is probably not your biggest problem. You're looking for a magic bullet that may not be there. I'd be more concerned with: - How easily can another programmer maintain your code? We…

> Stop worrying about how well your code performs and focus on more important things.

It's very naive to think that that's an acceptable tradeoff in every situation. Would you accept it if chrome/FF/ suddenly consumed an extra 30% of memory and CPU time after a single update, because the developers decided that the HTML rendering code wasn't readable enough? Or if you're writing code for cars that needs a response time in sub millisecond ranges to delay for hundreds of milliseconds before engaging traction control because the code wasn't well labelled, so it was rewritten?

There are plenty of cases where performance is absolutely critical, and it is the most important thing.

Re: Ask HN: What are the 20% tips that will get my code to performance 80% faster?

#42
post #13

When writing if-statements that have an AND, always put the quickest executing condition first. Don't use ORM's naively. Be careful about what you call in a loop. Those three alone account for most of the execution speed issues I've encountered. And they're all low-hanging fruit.

>always put the quickest executing condition first. isn't it put the most probably true condition first?

when choosing between

  A and B
and

  B and A
You want to compare expected execution times, which are:

  E(A) + p(A) E(B)
(E(X) =expected execution time of X, p(X) = probability that X evaluates to true) and

  E(B) + p(B) E(A)
The first is larger if

  (1 - p(B)) E(A) > (1 - p(A)) E(B)
End result is that it may be better to put the expensive call first, if the probability of the cheap call being true is much higher than that of the expensive call.

[Feel free to extend this model by adding the time needed to make or not make the branch around the second part]

In practice, if one is a function call and the other is not, put the function call last, then, if performance is inadequate, measure.

Re: Ask HN: What are the 20% tips that will get my code to performance 80% faster?

#43
- Learn about big-O complexity.

- Learn the big-O complexity of your language's data structures.

- Benchmark places in your code that do lots of things with those data structures, especially loops. Write a couple variations with the structures with the best big-O complexity to find the fastest one for your use-case (it can sometimes be surprising).

- Conditionals in loops can hide all kinds of complexity. If you are computing the same thing each evaluation in a loop, compute it once before entering the loop instead and replace it.

- Try to do as much with the data that's in memory as possible, before replacing it with stuff further down the memory hierarchy. If your language let's you care about L1, L2 cache optimization, learn about that. Nothing will slow code down like having to move data up and down the memory hierarchy.

- If you have to operate on lots of data, look for ways to parallelize work on that data. Modern CPUs have lots of cores, single-threading only uses a fraction of your computational power.

- If you have complex conditionals, try to find ways to optimize and limit the branching: short circuit booleans, eliminate expensive to compute conditionals etc. Sometimes complex business rules can be rewritten in simpler ways that greatly reduce branch prediction hits.

- Try to squeeze as much performance out of a single machine as possible. As soon as you start sharding your code across multiple systems, your memory hierarchy problem becomes a network bandwidth problem, which is about as bad as you can get. If your problem fits on one machine, it can almost always be made faster than splitting it across n-machines.

- Spend time really thinking about your algorithms. I've seen all kinds of cases where a slow algorithm could be trivially sped up by taking a different approach.

Re: Ask HN: What are the 20% tips that will get my code to performance 80% faster?

#44

Use hash tables, hash maps, dictionaries, JavaScript objects, etc. (whatever it's called in your language of choice) for indexing. This gives you constant time access to data by whatever properties you want to index on (usually by id). Also, use libraries and reuse your own code/routines. If you find a faster way to do something, all the code that used those routines will benefit immediately.

Corollary - some times hash tables aren't the fastest data structure. You can often replace a hash with a trie to see a considerable improvement (Caveat emptor ...)

Re: Ask HN: What are the 20% tips that will get my code to performance 80% faster?

#46
post #42

Earlier quoted context omitted.

>always put the quickest executing condition first. isn't it put the most probably true condition first?

when choosing between A and B and B and A You want to compare expected execution times, which are: E(A) + p(A) E(B) (E(X) =expected execution time of X, p(X) = probability that X evaluates to true) and E(B) + p(B) E(A) The first is larger if (1 - p(B)) E(A) > (1 - p(A)) E(B) End result is that it may be better to put the expensive call first, if the probability of the cheap call being true is much higher than that of…

[deleted]

Re: Ask HN: What are the 20% tips that will get my code to performance 80% faster?

#49
This is fairly specific optimization advice which applies to only a subset of people's code, but: Write your own SQL queries.

ORMs are notorious for writing inefficient queries once you get more complicated than selecting a single row from a simple table, and trying to optimize them without writing a SQL query will make your code all but unreadable. This isn't to say don't use an ORM, but if you need to optimize, your code speed and code clarity will be better off with raw SQL.

More generalized performance advice: Keep heap memory allocations to an absolute minimum. Heap access is more likely to result in cache misses, and the bookkeeping related to allocating and freeing memory can quickly add up (even if you're not doing it explicitly).

Globals and stack allocations are almost universally faster.

A resource which popped up on HN yesterday might offer a bit more insight on how to design for optimal performance: https://news.ycombinator.com/item?id=8978081

Post reply on HN