| - 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. |