[aaronchall]

Code that you don't write consumes zero clock cycles.

Learn your language well, so that you can use data structures and builtin functions as they are intended, and you can expect them to be pre-optimized for you. Learn in principle what is optimal, and write in that fashion.

Know the documentation, and follow best practices that the docs recommend - when the compiler/language gets updated, you'll get free optimizations.

Use semantic names, none of this i, j, x, y stuff (unless you're writing totally abstract math) and don't use nebulous names like "helper," when you can be more precise. Better names help you think more precisely about your code and what you want it to do, so you can avoid unnecessary transformations, materializations, and calculations.

When you've finished the program (all the unittests and acceptance tests pass), then profile. Focus on the bottlenecks. In this way, you'll get your optimal Pareto performing code.

[tbirdz]

Code that you didn't write but that is being executed still consumes clock cycles. Standard library functions and data structures still have code that executes on the machine, you can't just handwave it away as consuming zero cycles just because you didn't write it.

[saalweachter]

I believe the intention was more Zen -- don't write code that isn't really necessary -- and the "use standard libraries" code was separate. (If you are using a language where the standard libraries are so poorly implemented that you can easily write better versions, you might want to consider using a different language.)

I would also add the cargo cult suggestion of "precompute and cache everything you can". Whatever can be done in an indexing process instead of a search process should be; whatever doesn't need to happen at serving time shouldn't.

[esailija]

> If you are using a language where the standard libraries are so poorly implemented that you can easily write better versions, you might want to consider using a different language.

Standard libraries are typically generalized for a wide array of use cases, you can easily write much faster implementation specialized to your needs if you have any idea what you are doing.

Sometimes standard libraries handle such ridiculous cases (e.g. many ES5 array methods and Function.prototype.bind) that your needs don't even need to be that special.