Skip to content

Instantly share code, notes, and snippets.

@iamnoah

iamnoah/performance.md

Created August 3, 2012 22:18
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save iamnoah/3252099 to your computer and use it in GitHub Desktop.
Save iamnoah/3252099 to your computer and use it in GitHub Desktop.
Download ZIP
Performance Best Practices
Raw
performance.md

When it comes to performance, never listen to anyone who tells you using some feature of JavaScript is slow (unless they tell you it's slow in an old version of a browser like IE8). Inevitably, one of the following will be true:

  1. X was slower than Y, but it isn't anymore.

  2. X is slower than Y, but it doesn't matter because that's not where your performance bottleneck is.

  3. X is slower than Y, but when the browsers auto-update tomorrow, X could be faster.

For example, we all know switch is slow. (Go ahead and follow the link. I'll wait.) Ooops. I hope you didn't spend a lot of time removing switches or complicate your code based on someone else's advice. If you did, I hope you did it because you had profiling data that proved that your performance bottleneck was the switch statement. Yea, that didn't happen. Well, at least you were following a best practice.

This is the only performance advice that will serve you well in the long term:

  1. Get data.

  2. Get more data. "It's fast on my machine" isn't good enough.

  3. Do something that you think will help.

  4. Get the same data, using the same initial conditions and same test cases.

  5. Is it better? Does it feel better?

  6. Confirm that the thing you changed didn't cause some sort of regression in functionality.

  7. Repeat until performance is acceptable.

Notice there is no "avoid doing X during development." Assuming you're not writing some sort of O(2^n) algorithm, you will have no clue when you're writing code where your bottleneck will be. Write clear, clean code. Then test it. If the perceived performance is acceptable under all reasonable conditions, don't mess with it. As long as your software feels fast to the user*, any performance improvements are going to be a waste of time. It may stroke your ego to be able to say you got a 200ms operation down to 45ms, but if your user isn't paying attention, then you wasted time you could've spent on feature work or bug fixes.

* Your definition of "user" may vary. There may be monetary costs to poorly performing software, in which case a "user" is the one writing the checks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment