Besides that, your wonderful optimization from today could actually be slower than with the next update to a browsers JIT, as by then it might actually optimize the case you were trying to speed up.
[...] We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Knuth is definitely right here. Now there are a few things to watch our for:
- Know your algorithms, no amount of low level optimization will make a
O(n³) algorithm noticeably faster.
- Use language idioms. Read some books, look at peoples code. In short: Don't make your JS look like C or Java. JS engines optimize for the JS way of doing things.
- Don't waste memory, you're dealing with a GC you cannot influence in any way whatsoever. Now, this problem won't show up until you're doing WebGL related stuff, but then it hits you hard. Use pooling and all the other usual tricks to avoid GC paused.
Now, all of the above aren't JS specific, they apply to pretty much all languages and especially any language that is using a GC.
So in the end it boils down do using a senseful architecture and algorithms that fit your problem domain and then, if you really really really find a performance problem (which cannot be solved through a better algorithm) only then you fiddle with loops and other low level constructs and try making it faster that way.