Array destructuring for multi-value returns (in light of React hooks)

Attention: Shared Google-externally
Authors: bmeurer@chromium.org, jasonmiller@chromium.org, rmcilroy@chromium.org
Last Updated: 2018/11/09

TL;DR This document presents an analysis of the performance impact when using array destructuring patterns to handle multi-value returns, especially in light of the recently announced React hooks.

Short link bit.ly/array-destructuring-for-multi-value-returns

Background

Array destructuring problem

Bytecode Analysis

Original ES2015 code

Potential action items

Babel loose mode code

Potential action items

Object destructuring alternative

Object destructuring the array

TurboFan Analysis

Original ES2015 code

Babel loose mode code

Potential Solutions

Special casing array destructuring

Generally cheaper iteration protocol (for arrays)

Stretch Goal: Swapping variables

Background

At React Conf 2018, Dan Abramov introduced a new concept called React hooks (video), which provides an elegant way to handle stateful components (aka hooking into Reacts state system and specifically the lifecycle hooks) without having to use component classes. A simple example of how this looks is:

This looks like a stateless component in traditional React, but it is stateful (the count state). Like stateless components this is executed every time the component Example is rendered. React internally memorizes the state for the count, so subsequent runs for the same instance of the component will have the same state.

Developers can use any number of these useState hooks (and other hooks) in a single component, for example:

Again, this will be executed every time the ExampleWithManyStates component is rendered (and useState will do its magic behind the scenes). Specifically the array destructuring runs on every render!

Array destructuring problem

I discussed the problem of potentially expensive array destructuring earlier this year at JSConfEU with Dan Abramov. We talked about using object destructuring instead, but the ergonomics for the developers would be worse, i.e. you'd need to agree on names for the pairs produced from the "use" functions, and you'd need more verbose syntax to assign it to local names.

This is harder to parse and probably leads to more subtle bugs than the array destructuring syntax above. Also array destructuring is not only interesting in the case of React hooks, but it's a general pattern that developers use often.

Dan's main argument back then was that React developers generally don't ship ES2015 code, but transpile their code via Babel first anyways, usually in loose mode. And Babel loose mode completely eliminates the array iteration:

But for the success of the web platform we don't want to incentivize transpilation as a long-term solution. Just looking at this simple snippet of code, it's already immediately obvious that transpilation is not a silver bullet, since it increases the size of the bundled JavaScript.

In order to make it attractive to ship untranspiled code (to modern browsers), we'll probably need to improve the way we deal with these special array destructuring (for multi-return values).

Bytecode Analysis

Let's consider this example (definitely very oversimplified, but necessary for the analysis):

It's specifically interesting to look at the generated bytecode (and any implicit overhead) here, because such render functions will likely execute quite often in bytecode, especially during page load, before they eventually tier up to optimized code.

Original ES2015 code

In V8 7.2 (as of 2018/10/31) this render function turns into the following Ignition bytecode:

Yes, that's really 335 bytes of bytecode! I've highlighted the different parts to make it easier to spot the different parts of the function inside the bytecode:

So the array destructuring const[x,setX]=state alone is responsible for 305 bytes of bytecode! The reason for this is that array destructuring uses the iteration protocol and the BytecodeGenerator inlines the iteration protocol completely into the bytecode for this case. Summarizing the cost of this, we need:

1. LOAD_IC for the Symbol.iterator lookup on the state (bytecode offset 15).
2. CALL_IC to instantiate the iterator, yielding a new JSArrayIterator instance (bytecode offset 21).
3. LOAD_IC to load the "next" method on the iterator (bytecode offset 37).
4. CALL_IC to call "next" for the first time, yielding a new JSIterResultObject instance (bytecode offset 62).
5. LOAD_IC to load "done" from the first iter result object (bytecode offset 80).
6. LOAD_IC to load "value" from the first iter result object (bytecode offset 91).
7. CALL_IC to call "next" for the second time, yielding a new JSIterResultObject instance (bytecode offset 117).
8. LOAD_IC to load "done" from the second iter result object (bytecode offset 135).
9. LOAD_IC to load "value" from the second iter result object (bytecode offset 146).

And to make matters worse, all of this has to be wrapped into a try-finally to implement the iterator closing. So that's a whopping 9 ICs and 3 temporary objects just to implement the array destructuring.

In order to understand why the above bytecode is this big, it might help to look at some pseudo JavaScript, which describes the destructuring assignment:

It's not 100% correct, but close enough to help understand the complexity of the iteration protocol for such (simple) cases.

Potential action items

AI(mythria) It might be worth sharing the feedback slots for the two "done" LdaNamedProperty and the two "value" LdaNamedProperty bytecodes, as it's very likely that a given iterator will always produce JSIterResultObjects with the same shape.

Babel loose mode code

Contrast this with the code that Babel produces in loose mode:

It's important to recognize that this is NOT semantically equivalent to the original ES2015 version! Ignition's BytecodeGenerator turns this into the following bytecode:

So this is only 45 bytes (aka 13% of the size of the bytecode for the original ES2015 function). Again highlighting the different parts to make it easier to read the bytecode:

Summarizing the cost here:

1. KEYED_LOAD_IC to load the zeroth element from _useState (bytecode offset 16).
2. KEYED_LOAD_IC to load the first element from _useState (bytecode offset 23).

So it's easy to see that this version will be a lot more efficient than the original ES2015 version, speaking in terms of the bytecode and the object allocation overhead in the interpreter version.

Potential action items

AI(mythria) One thing that seems interesting here is that the two LdaKeyedProperty bytecodes get distinct feedback vector slots (4 vs 6). That might be something worth optimizing, having all KEYED_LOAD_ICs accessing the same object share a single feedback vector slot, since the feedback that is collected is the pair of map and handler, where the handler is usually one of the LoadElementStubs (i.e. it's the same for loading 0 and 1).

Object destructuring alternative

An alternative approach I suggested to Dan Abramov was to consider object destructuring instead of array destructuring (as mentioned above). So this would look something like this:

Looking at the bytecode in Ignition we see:

This is 64 bytes, which is not as ideal as the Babel loose mode version, but significantly better than the original ES2015 array destructuring version. Again using color boxing to explain the bytecode in terms of the original JavaScript:

Summarizing the cost of the destructuring:

1. LOAD_IC to load the "val" from the state (bytecode offset 35).
2. LOAD_IC to load the "set" from the state (bytecode offset 41).

Again no additional temporary objects need to be constructed.

Object destructuring the array

Jason Miller points out that it is also possible to destructure the return value of array-returning functions like useState() using object destructuring with numeric keys, avoiding the cost of the iteration protocol:

A somewhat representative benchmark seems to indicate this outperforms both the Array destructured approach and Babel’s transpiled output:

Looking at the bytecode reveals that it's indeed close to the object destructuring with real named fields (i.e. not using numeric indices):

This is 65 bytes of bytecode, so pretty good. Color boxing to match it back to the bytecode:

But this solution suffers from the same problem as the object destructuring, it's not really easy on the eyes. You don't need to agree on names, but object destructuring with numeric indices is not something JavaScript developers come across often, so it might lead to surprises, especially with newcomers.

TurboFan Analysis

Now it's worth looking into the optimized code as well. The render functions will likely be called often while interacting with a React web application, so there's a good chance they'll become hot.

Original ES2015 code

Let's first consider the optimized code that TurboFan generates for the original ES2015 array destructuring version:

This is admittedly a lot harder to read than the bytecode. Using color boxing we can again match it back to the original code:

The interesting aspect here is that TurboFan completely eliminates not only the allocation of the JSArrayIterator instance, but also the two JSIterResultObject instances (there's no allocation code in the red part, although admittedly the optimized code could still be a little bit better).

Babel loose mode code

The optimized code for the JavaScript generated by Babel in loose mode looks like this:

This is very close to the perfect code you can generate here. Color boxing to read the optimized code:

This code not only avoids any unnecessary allocations, but also executes only the minimal number of instructions, i.e. it even eliminates the memory access for setX = _useState[1], since TurboFan is able to tell that setX is not used afterwards (notice that the bounds check remains in the code though).

Potential Solutions

Special casing array destructuring

Given the above analysis and the fact that during page load (aka for the initial render), most code will run in the interpreter, it probably makes sense to invest into the generated bytecode for array destructuring. The observation from TurboFan here is that if the engine can prove that no one messed with the Array.prototype[Symbol.iterator] and that the intrinsic %ArrayIteratorPrototype%.next() is unchanged, we don't need to actually do the iteration protocol. So we could recognize simple array destructurings like

and instead of blowing that up into the full iteration protocol inlined into the bytecode, have a single bytecode that does it instead, i.e.

DestructureArray iterable, ra-rb

which takes an iterable and produces a register list. This bytecode would also collect feedback about the iterable for the TurboFan optimization, so TurboFan is probably able to generate the perfect code sequence in case the iterable is an JSArray instance (with fast elements and no elements on the Array.prototype chain); we can even take it further one step and go MEGAMORPHIC if the iterable has less than two elements, which means TurboFan could get along with just a single bounds check followed by two element loads. So that might look something like this

CheckHeapObject(iterable)
CheckMaps[array map](iterable)
length = LoadField[length](iterable)
CheckBounds(1, length)
elements = LoadField[elements](iterable)
ra = LoadElement(iterable, 0)
rb = LoadElement(iterable, 1)

which is the best optimized code possible and will even beat the Babel loose mode code (although not by a lot).

More important than the TurboFan considerations is that for Ignition we can completely encapsulate the iteration protocol in one bytecode (in the same spirit as for the ArrayCloneIC), which means even before going to optimized code we can skip the iteration protocol if we see that the iterable is a JSArray and no one messed with the iterator methods (aka the FastArrayIteration protector is intact).

We will probably have to limit this to one-/two-element patterns initially, since TurboFan cannot really handle stub calls that return more than two values (we once supported three to implement some part of for..in, but fortunately we improved that since then, so there was no need for 3-return any more), and for the case where DestructureArray doesn't have usable feedback TurboFan needs to insert a builtin call to handle the generic case.

Generally cheaper iteration protocol (for arrays)

Doc Faster iteration protocol

Ross McIlroy suggested that we could do something similar to how we support for..in and have a bytecode that looks like this:

[iterator, next_method] = GetIterator(iterable)
loop {
  iter_result = IteratorNext(iterator, next_method)
 if (IteratorComplete(iterator, iter_result)) break;
 value = IteratorValue(iterator, iter_result);
 …
}

where for the case of a JSArray iterable with fast elements when both the Array.prototype[Symbol.iterator] and %ArrayIteratorPrototype%.next are unchanged, the GetIterator bytecode does nothing but returns the iterable for iterator and Smi #0 as the next_method, and IteratorNext returns the index (the current value of next_method), and increments the next_method Smi. In IteratorComplete we perform the bounds check against the iterator.length (iterator will be the JSArray iterable), and finally IteratorValue will load the value at the iter_result index (might hit the slow path and walk up the prototype chain). For the generic case, all the iterator and iter result objects could be allocated and held in the respective registers.

This wouldn't be quite as fast as the special case approach above, but should be comparable to the Object destructuring array approach for fast JSArrays. And it would allow us to sort out for..of as well. Also this would be easier to match to the specification, which has similarly named abstract operations. Some of these operations will have to collect feedback to allow TurboFan to generate perfect optimized code.

Stretch Goal: Swapping variables

A similar pattern that developers got quite excited about in ES2015 is the ability to swap the values of variables with just a single line of code, i.e.:

This currently suffers from the same problems as the general case, and would also benefit from a special DestructureArray bytecode. But in reality it would be even better to recognize this and have a Swap bytecode that completely avoids any temporary allocations if the array iteration is not messed up, i.e. something like this:

Swap ra-rb

It's currently unclear how important it is, so maybe just having the DestructureArray bytecode which solves a more general problem might be enough. Most uses in the wild will be transpiled code anyways, so it's hard to estimate the importance.