SXSW 2012: JavaScript Performance MythBusters (via JSPerf)

Chris Joel
CloudFlare, Developer

John David Dalton
Uxebu, JavaScript Developer

Kyle Simpson
Getify Solutions, Owner

Lindsey Simon
Twist, Developer

Presentation Description

JavaScript is everywhere from mobile phones and tablets to e-readers and TVs. With such a wide range of supported environments developers are often looking for an easy way to compare the performance between
snippets, browsers, and devices. jsPerf.com, a site for community driven JavaScript benchmarks, was created to help devs do just that.

Join Mathias Bynens and John-David Dalton from jsPerf.com, Chris Joel from Cloudflare.com and Lindsey Simon from Google/Browserscope in this panel discussion on some of the best dev-created benchmarks and most interesting practices debunked by real-world tests.

Presentation Notes

Browserscope and jsPerf

Open-source, community-driven project for profiling browsers. Really good at helping inform developers by providing number crunching and actual data. The whole idea is that anyone can reproduce results with any type of hardware (crowdsourcing).

Explicit Goals:

  • Foster innovation by tracking functionality
  • Push browser innovation, uncover regressions
  • Historical resource for web developers

Myths

  1. Your for loops suck: rewrite all your code and use: while –i BUSTED
  2. Double your localStorage read performances in Chrome by getting by index. TRUE
  3. The arguments object should be avoided. BUSTED (but isn’t as good in Opera)
  4. Frameworks (like jQuery) are always better at managing performance than you are, so just use what they provide. BUSTED
  5. Converting a NodeList to an array is expensive, so you shouldn’t do it. For instance document.getElementsByTagName() returns a NodeList, not an array, and then iterating over it compared to an array after taking the performance hit of converting it. BUSTED (also see: Static node list, which is closer to a performance with an array)
  6. Script concatenation and/or <script defer> is all you need to load JS performantly (aka “Issue 28“). POSSIBLY. The average website has over 300K of JavaScript. The best thing to do with your JavaScript is to concatenate all your files, but then split them into about 100K sizes. This highly increases the speed at which your browser can download if you’re downloading these in parallel. Also, chunking up your code into pieces where you separate never-changing javascript with frequent you will help with browser caching. Lazy loading (pulling in the important file first and them the others).
  7. Eval is evil, it’s too slow and quirky to be considered useful. BUSTED The performance is pretty much equal with all benchmarks.
  8. Regular expressions are slow and should be replaced with simple string method calls using indexOf(). BUSTED Engines are getting faster now with RegEx.
  9. OO API abstraction means you never have to worry about the details (including the performance). BUSTED Your API design matters more than it just being OO.
  10. Type torsion (===) takes more processing power than a regular comparison (==). BUSTED There is a difference, but it’s so tiny you shouldn’t be concerned.
  11. Caching “nested property lookup” or “prototype chain lookup” helps (or hurts) performance BUSTED In most cases the browser engine already makes the cache, and this wont matter at all
  12. Operations which require an implicit primitive-to-object cast/conversion will be slower BUSTED For instance, when converting a number to a toString() or toNumber() it doesn’t affect performance
  13. Scope chain lookups are expensive BUSTED
  14. Use switch statements instead of if/else if for better performance. POSSIBLY. In most cases this is true, except in Safari and Mobile Safari. The panel recommended to just use what you need.
  15. Use native methods for better performance. BUSTED

3 Responses to “SXSW 2012: JavaScript Performance MythBusters (via JSPerf)”

Leave a Reply