• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Holistic JavaScript Performance
 

Holistic JavaScript Performance

on

  • 940 views

Talk given at Velocity 2011.

Talk given at Velocity 2011.

Statistics

Views

Total Views
940
Views on SlideShare
925
Embed Views
15

Actions

Likes
1
Downloads
12
Comments
0

1 Embed 15

http://lanyrd.com 15

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Holistic JavaScript Performance Holistic JavaScript Performance Presentation Transcript

    • HOLISTICPERFORMANCE John Resig
    • PerformancePerformance analysis is amazingly complex There is no, single, silver-bulletDon’t want to compromise quality in favor ofperformanceAlso want to communicate the changes in a realisticway
    • Analyzing PerformanceWall-clock time Time in different browsers CPU consumptionMemory consumption Memory leaksBandwidth consumption Parse timeBattery consumption (Mobile!)
    • Dictionary Lookups in JavaScriptAn interesting example for looking at performance.Most frequent concern: File SizeMany solutions only optimize for file size Disregard parse time, or other performance aspects
    • Naïve SolutionPull in a raw list of wordsPush it into an object for fast property lookupsUses a lot of file sizeVery fast lookups
    • TrieA compact structure forstoring dictionariesOptimizes heavily for filesizeCan be rather expensiveto parseCan also use a lot of memory
    • File Size of Dictionaries1100KB 825KB550KB 275KB 0KB Plain String Binary String Simple Trie Optimized Trie Suffix Trie Succinct Trie Normal Gzipped
    • Load Speed of Dictionaries Time to load the dictionary once in Node.js on a 2.8 GHz Core i7. 150ms112.5ms 75ms37.5ms 0ms Plain String Binary String Hash Trie Succinct Trie
    • Search Speed of Dictionaries Time to look up one word. 6ms4.5ms 3ms1.5ms 0ms Plain String Binary String Hash Trie Succinct Trie Found Missing
    • Private Memory Usage of Dictionaries After loading the dictionary once. 11MB8.25MB 5.5MB2.75MB 0MB Plain String Binary String Hash Trie Succinct Trie
    • dynaTrace
    • dynaTraceOne of the best tools available for analyzing the fullbrowser stackDig into CPU usage, bandwidth usage, and evenperformance of browser-internal methodsWorks in both IE and Firefox
    • Practical PerformanceThink about the larger context Pre-optimization is dangerousCode qualityImportanceCross-browser compatibility
    • Performance in the jQuery Project
    • Rule 1: Prove it.
    • Prove it.Any proposed performance optimization must beundisputedly proven.Show us the proposed changes and how it’ll affectperformance across all platforms.How? JSPerf. http://jsperf.com/
    • JSPerfJSPerf is a great toolMakes it very easy to build a reproducible test: http://jsperf.com/valhooks-vs-val/2
    • JSPerfJSPerf builds on some of the earlier analysis I did in2008 http://ejohn.org/blog/javascript-benchmark-quality/Runs tests the maximum number of times in 5 secondsEven does optimization to make sure there is less loopoverheadAlso uses a Java Applet for even better timer accuracy
    • Rule 2: See the Big Picture.
    • See the Big Picture.Micro-optimizations are death.Doesn’t matter how much you unroll a loop if that loopis doing DOM manipulation.Most crippling web app performance is from DOMperformance issues.Pure JS performance is rarely an issue.
    • Prove the use case.If you’re proposing an optimization you must provewhat it’ll help.Show real world applications that’ll benefit from thechange.This is especially important as it’ll help stop you fromwasting time on performance issues that don’t matter.
    • Rule 3: Clean Code.
    • Clean Code.We won’t compromise our code quality in exchange forperformance.Almost all code quality compromises come fromneedless micro-optimizations.~~(1 * string) vs. parseInt( string )+new Date vs. (new Date).getTime()Don’t even get me started on loop unrolling.
    • Rule 4: Don’t Slow IE.
    • Don’t Slow IE.Just because performance gets better in one browserdoesn’t mean it’ll get faster in all browsers.You shouldn’t compromise performance in otherbrowsers for the sake of one. (Unless that browser is IE, always improve IE performance.)
    • Communicating the ResultsCreating realistic testsCommunicating in an effective manner
    • Creating Realistic Tests
    • RealismIt’s incredibly hard to create realistic test casesIt’s important to look at actual applicationsWe frequently use Google Code Search to find out howpeople are using our APIs (This gives us the knowledge that we need when we want to deprecate an API as well.)
    • Communicating the Results
    • BrowserscopeCollection of performance resultsOrganized by browserJSPerf plugs right in
    • Creating ResultsPull the results directly from BrowserScopeBest: Compare old versions to new versions Within the context of all browsers
    • .val() (get) (Number of test iterations, higher is better.)700000525000350000175000 0 Chrome 11 Safari 5 Firefox 4 Opera 11 IE 7 IE 8 IE 9 1.5.2 1.6
    • CompetitionYou might be inclined to compare performance againstother frameworks, libraries, applications, etc.This tends to create more problems than it’s worth And the comparison isn’t always one-to-oneIf competing, agree on some tests firstWork with your competition to create realistic tests
    • Compete Against YourselfIn the jQuery project we work to constantly improveagainst ourselvesEvery release we try to have some performanceimprovements Always compare against our past releasesRewriting API internals is a frequent way of gettinggood performance results
    • More InformationThank you!http://ajax.dynatrace.com/ajax/en/http://jsperf.comhttp://www.browserscope.orghttp://ejohn.org/blog/javascript-benchmark-quality/http://ejohn.org/