luke.dewitt

$ cd ~/talks/profiling-javascript-performance

2019-09-13Web Unleashed 2019Toronto, ON

Profiling JavaScript Performance⁠

A beginner's tour of the Chrome profiler: finding bottlenecks in your JavaScript without leaning on console.log.

$ open slides

  1. Profiling JavaScript Performance
  2. Welcome
  3. Luke DeWitt EAST COASTER / HUSBAND / FATHER OF 3 UNDER 5 (TIRED) / DEVELOPER / DIRECTOR OF WEB SERVICES Greetings!
  6. JavaScript • Performance is important • Everyone loves fast sites • JS continually redefining itself • Low barrier to entry • Simple to learn • Frameworks
  7. JavaScript ❤❤"
  8. Let’s Dive In
  9. JavaScript • The problems are the same, front or back end
  10. JavaScript • Single threaded • One “chunk” at a time
  11. But Luke!
  12. JavaScript • Single threaded • One “chunk” at a time • Avoid blocking code
  13. JavaScript • Blocking Code • Render blocking • Unresponsive UIs • Accessibility Issues • Bad UX
  14. Call Stack
  15. Call Stack • This is our “single thread” • Last In, First Out • Code added when called (stack frame) • Popped off when “returned” • Repeat until empty • Do it again
  16. The Call Stack call stack function1() function2() function3() function4() function5()
  17. Call Stack Example call stack go() start() andThen() andThenMore() andFinally() console.log()
  18. node --inspect app.js node --inspect-brk app.js
  21. Profile Graph
  22. Recursion Example call stack recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion()
  23. Recursion Example call stack recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion() recursion()
  24. Example
  26. Call Stack Example call stack console.log() cube() parseInt()
  27. Call Stack Example call stack console.log() cube()
  28. Call Stack Example call stack console.log() cube()
  29. Profile Graph
  30. JavaScript
  31. JavaScript • APIs are exposed • Timers • Callbacks • Promises • Async/Await • Limits “Blocking” code • setTimeout === window.setTimeout
  32. Event Loop • Responsible for pushing items onto the Call Stack • Responsible for executing the top most stack frame • Runs when the stack is empty • Also responsible for pulling stack frames from the queue(s) onto the Call Stack for execution
  33. • Implemented by the browsers / node runtime • “Web APIs” for browsers • C++ for node • Essentially act as threading mechanisms • Better code execution • Multiple Queues External APIs
  34. JavaScript call stack queue event loop function1() function2() function3() external apis
  35. JavaScript call stack queue event loop external apis setTimeout(myCB)
  36. JavaScript call stack queue event loop external apis timer(myCB)
  37. JavaScript call stack queue event loop external apis myCB()
  39. XHR & Promise Example
  40. XHR & Promise Graph
  41. XHR & Promise Graph (Request)
  42. XHR & Promise Graph ( Response)
  43. XHR & Async/Await Example
  44. ... tooling...
  45. console.log
  46. console.profile console.profileEnd
  47. Example
  48. Example Graph
  49. Example
  50. Moment of Truth
  51. Open Source https://dewey.codes
  52. Project at a Glance • Started building it in 2014 • Domain knowledge / interest existed • Learning project • Hard deadline • … rushed
  53. The Sandbox
  54. Current Code (API Call)
  55. Profile Graph (API Call)
  56. Profile Graph (API Call) Time To Actual Request Index
  57. Profile Graph (API Call) TTARI 22.387ms TTARI SD 0.514ms
  58. Current Code (API Call)
  59. MOAR OPEN SOURCE!!
  60. Updated Code (API Call)
  61. Profile Graph (API Call w/ Axios) 18.4ms 1.09ms TTARI TTARI SD
  62. TTARI Axios 18.4 ms Request 22.387 ms 18 Improvement o o
  63. We can do better…
  64. Vanilla Code (API Call)
  65. Profile Graph (API Call w/ Vanilla JS) 15.9ms 0.535ms TTARI TTARI SD
  66. TTARI Axios 18.4 ms Request 22.387 ms Vanilla 15.9 ms 29 Improvement o o
  67. TWENTY-NINE
  68. Thank you for coming!
  69. redspace.com / T (902) 444.3490 FACEBOOK REDspace TWITTER @theREDspace LINKEDIN The REDspace LUKE DEWITT @whatadewitt Thank You!
  70. Thank You! Oh, by the way, we’re hiring! https://www.redspace.com/jobs
1 / 70
download pdf ↓

$ cat notes.md

JavaScript has a low barrier to entry, which is great, and it’s also why so much slow JavaScript ships without anyone noticing. This talk was a beginner’s look at the profiler, so you can find the slow parts instead of guessing at them.

How JavaScript runs

  • It’s single threaded: one chunk of work at a time. Blocking code means render blocking, unresponsive UIs, accessibility issues and a bad experience.
  • The call stack is that single thread. Calls push a frame on, returns pop it off, last in, first out, until the stack is empty.
  • Timers, callbacks, promises and async/await hand work to external APIs (Web APIs in the browser, C++ in Node). When it’s done, the callback waits in a queue, and the event loop moves it onto the call stack once the stack is empty.

Profiling it

  • In Node, start your app with node --inspect app.js (or --inspect-brk to pause on the first line) and attach Chrome DevTools.
  • The profile graph shows the call stack over time, so you can see what ran, for how long, and what called it.
  • Wrap the code you care about in console.profile() and console.profileEnd() to record just that part, instead of sprinkling console.log everywhere.

Moment of truth

Then I profiled my own open source project, the Yahoo Fantasy Sports API library. I started it in 2014 as a learning project with a hard deadline, so… it was rushed. Using its sandbox, I measured the time from calling the library to the actual request going out:

VersionTime to request
Original (request)22.4 ms
Axios18.4 ms (18% faster)
Vanilla JS15.9 ms (29% faster)

Twenty-nine percent, just by profiling code I thought I already knew.

visitor@whatadewitt: ~