Javascript Performance

Mike Sherov

Core UX Team @ Skillshare

I am performance, and so can you!

Overview

We've been busy
Perf Prereqs
Common Perf Strategies
Perf Mechanics
What's Next in JS Perf?

We've been busy lately...

Very busy...

And we've achieved results.

40% npm@5.3.0 vs. npm@5
70% npm@5.3.0 vs. npm@4
60% Webpack resolve phase
50% Webpack Uglification
95% Webpack Plugin Speed

Perf Prereqs

You can do it!
Everything is slow
No premature optimizations

You can do it!

Perf has some magic... But mostly, it's about focus
Easy to fire up a profiler. After a while, it's like any other tool
Most perf patches are really straightforward

Everything is slow

Webpack is a slow codebase. npm too
"Make it work. Make it right. Make it fast."
You think someone else made it fast already... They haven't

No premature optimizations

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%

Common Perf Strategies

Big O Notation - Avoid O(n^2)
Caching and Memoization
Avoiding Garbage Collection
Avoid Unnecessary Immutability
Don't do things you don't need
Other JS Magic Learnings

Big O Notation - Avoid O(n^2)

O(1) - 1 or m ops
- key lookup: `if (obj.keyName)`
O(n) - n or n*m ops
- val in Array:`if (arr.includes(value))`
- multi key in Object: `keys.every(key => obj[key])`
O(n^2) - n^2 or n^2*m ops
- multi val in Array `arr2.every(val => arr.includes(val))`

Given n inputs, and some small constant m:

Big O Notation - Avoid O(n^2)

Why do we see a lot of n^2 in JS?

var obj1 = {a: 1}
var obj2 = {b: 2}

console.log('es5 - broken, but O(1)');

function SetAddBroken(obj, set) {
  set[obj] = true;
}

function SetHasBroken(obj, set) {
  return !!set[obj];
}

var fakeSet = {};
SetAddBroken(obj1, fakeSet);
console.log(SetHasBroken(obj1, fakeSet));
console.log(SetHasBroken(obj2, fakeSet));
console.log(fakeSet)

console.log('es5 - works, but O(n)');

function SetAddWorks(obj, set) {
  if (!set.includes(obj)) { set.push(obj); }
}

function SetHasWorks(obj, set) {
  return set.includes(obj);
}

var fakeSet2 = [];
SetAddWorks(obj1, fakeSet2);
console.log(SetHasWorks(obj1, fakeSet2));
console.log(SetHasWorks(obj2, fakeSet2));

console.log('es6 - works, and O(1)');

var set = new Set();
set.add(obj1);
console.log(set.has(obj1));
console.log(set.has(obj2));

https://jsbin.com/zoxasokise/edit?js,console

Caching + Memoization

Caching - storing the results of a heavy operation for later retrieval
Memoization - caching function calls by their parameters (works only for pure functions)
- https://github.com/npm/read-package-json/pull/70
- https://github.com/npm/hosted-git-info/pull/24
- Careful when caching objects... if they are mutated somewhere else, it mutates the cache! oops!
- Ensure your function is pure... params like `filename` often indicate "read from disk", which is impure! oops!
- Careful in general! Caching is indistinguishable from a memory leak and can cause GC

Avoid Garbage Collection

Js is reference counted. After a certain amount of allocation, JS pauses and does GC to free up memory.
Less Allocation == Less GC.
Use profiler to find GC events, and see if a common function is preceding them!
Hoist nested function declaration s. Typically in the form of `forEach(() => x)`.
Use WeakMaps to avoid dangling references!
- Great for memoization!
~~Gotcha, regex literals are allocations! Hoist them!~~
- https://github.com/webpack/webpack/pull/5194
- https://bugs.chromium.org/p/v8/issues/detail?id=6556

Avoid Unnecessary Immutability

I can hear the FPers groaning in the background!
The fact remains that fast code is often the opposite of clean code. If you need to be fast, `Object.assign({}, obj)` is a deoptimization
Especially avoid dogma, even if it's from ESLint

Don't do things you don't need

Fastest code is no code! O(0) beats O(1)
This is super generic advice, but here's some specifics. Are you...

Other JS Magic Learnings

Surprise... I won't teach them to you!
They're useful, but they're arbitrary and ever-changing
Best to file bugs with JS Engines than succumb to wisdom of elders
Instead, here's a list of things that were magic (but fixed)
- try/catch couldn't be optimized
- function character length (including comments!) dictated whether the function could be inlined
- regex literals weren't auto-inlined
- This IIFE `(function a(){}())` triggered eager parse but this one `!function a(){}()` didn't

Perf Mechanics

Isolate Environment
Instrument Application
Form Hypothesis
Test Cheaply
Fix Issue
Verify Fix
Publish Results

Isolate Environment

Ensure you own your CPU, and that nothing is hogging it
- Plug in your power cord
- Close all applications except one tab of chrome
- `docker-machine down`
- `sudo mdutil -a -i off`
Use `nvm` to manage runtimes
Test in the most common envs for your users

Instrument Application

`node --inspect-brk file.js`
Open Chrome
Paste URL

Form Hypothesis

Use profiler to discover
- hot spots
- cold spots
- GC pauses
Examine code to see what's happening
Identify possible source of slowness

Test Cheaply

Can you just comment out the code in question?
- Great for "don't do what you don't need" fixes
Can I replace the return value with a dummy value?
- Great for Caching/Memoization fixes
Can I quickly replace this with a Set or Map?
- Great for Big O Notation fixes

Fix Issue

Ironically, the actual coding is often the simplest part.
Most perf fixes are boring.

Verify Fix

Ensure you run the code uninstrumented many times before and after the fix.
Record times for before and after.
Instrument again. Ensure that the time savings come from where you wanted them to come from! Oftentimes, one perf fix has unintended perf consequences elsewhere!

Publish Results

It isn't enough to say it's faster! As with most programming tasks, there is a social component!
Educate the community! Publish the findings and your process!
File bugs with browsers and compilers when something seems wonky. It works!

What's Next in JS Perf

Node 8.3.0
Web Assembly
Binary AST proposal
cipm - shameless plug

Node 8.3.0

Replaces Crankshaft with Turbofan + Ignition
YMMV, but expected 10-20% across the board perf gains
Much easier to implement new optimizations going forward

WASM

Literally, Web Assembly. Intended to allow C and C++ to compile to the Web Browser in a more efficient bytecode than JS currently allowed.
Can call into and out of JS, has access to DOM, etc. everything that JS has.
Intended to be a language compile target, not an authoring language with native performance. Exciting times indeed.

Binary AST format

For JS to run in the browser, it must be downloaded, parsed, and executed, in that order.
Binary AST is:
- Binary instead of text, which means a smaller payload size.
- An AST, which means it's already parsed.
Currently in Stage 1 of TC39, and many folks doubt it'll get to Stage 4, but an interesting concept!

CIPM

npm has many use cases:
- install from package-lock.json OR package.json OR node_modules dirs
- publish, update, link
cipm cuts the fat and several parts of npm's workflow, and is intended only for "install as part of a CI workflow":
- installs from package-lock.json
- run lifecycle scripts for the installed packages
- should result in ~20 - 30% speed boost
I can use the help, if anyone wants to get involved!

Javascript Performance

Overview

We've been busy lately...

Very busy...

And we've achieved results.

Perf Prereqs

You can do it!

Everything is slow

No premature optimizations

Common Perf Strategies

Big O Notation - Avoid O(n^2)

Big O Notation - Avoid O(n^2)

Caching + Memoization

Avoid Garbage Collection

Avoid Unnecessary Immutability

Don't do things you don't need

Other JS Magic Learnings

Perf Mechanics

Isolate Environment

Instrument Application

Form Hypothesis

Test Cheaply

Fix Issue

Verify Fix

Publish Results

What's Next in JS Perf

Node 8.3.0

WASM

Binary AST format

CIPM

Gentle Reminder:

Anyone can do this!

Comments?

Questions?