Hi, everyone.

My name is Maxim Koretskyi, but I'm also known as the Wizard because I like to talk and write

about complicated stuff, topics that sometimes are seen as mysterious, and hence the name

The Wizard.

I'm going to be talking about why Angular and React, the top web frameworks we have

today, are so fast.

I will present a few JavaScript opened myself techniques that these frameworks use to make

JavaScript run fast.

Now, I work at AG Grid.

This is where we develop the best data grid in the world, so, if you need the data grid,

we have a free community version with a lot of features, so definitely give it a try if

you need data grid.

I'm also the founder of Angular and dev community where we write and publish articles about

advanced topics of Angular.

So, we will be talking about three things today: monomorphism, bitfils, and filters.

How many know about monomorphism, watch talks?

Something?

Okay.

I watched a talk by Benedict last year, gave a talk about monomorphism.

I will give you an overview of what it is.

I will talk about bitfils and how Angular uses structure known as bloom filters.

Let's start with monomorphism.

I do a lot of reverse engineering.

I sit at the computer with debugger and go through the sores of the frameworks.

These are the comments that I found inside Angular and React sources.

So these are the comments by technical leads of the frameworks, and they talk about hidden

class.

And internal data structures called fibre and view nodes.

They want to ensure that these internal data structures share the same hidden class, and

that is to make property access monomorphic.

So a bunch of words when I first encountered that, I didn't really know what they were

talking about.

We need to clarify today what is hidden class?

What is monomorphic property access?

Why is it important in what are these data structures, like fibre and view nodes?

Let's start with data structures.

Fibre nodes and view nodes in Angular are used internally to represent a template, basically.

When you define a component, this is the declaration of a component in Angular.

Angular uses view nodes, data structures, that it creates to represent a template.

They define the metadata needed to render the DOM, and it also specifies which part

of the DOM needs to be up dated.

Something called bindings.

How many of you work with Angular?

The same thing in React.

We also define components, we define a template, and React uses fibre node.

This is new React fibre 16 architecture.

It uses fibre node to represent the DOM.

How many use React?

About 40 per cent.

Fibre nodes and view nodes are used by these frameworks to represent a template.

This is something in between the declaration of a component template and the DOM.

What is common between these data structures is that they are used a lot when these frameworks

process changes.

Imagine there's a function called update node, an example of a function, there are a bunch

of functions similar to this one in both frameworks.

This function takes in a data structure, fibre or view node as the first parameter and then

it reads some property.

What is interesting that these kind of functions and the property access to easily exceed 10,000

times.

So it reads the data structure 10,000 times, every single times, changes are being processed.

So it can happen a few times per second.

You can imagine how many times the framework in JavaScript needs to have access to the

property.

The problem is virtual machines bike V8, it's a complicated process to figure out where

exactly in memory for the value of the property is stored.

Hence the virtual machine has optimisation techniques they use to make the process faster.

First, let me explain to you: when I was trying to figure out all that stuff, the question

I had is why is it complicated?

Why is it complicated to figure out where the value is, right?

And the answer is because of something called shapes or hidden classes.

That is exactly the hidden class that Sebastian talked in his comment.

So every single JavaScript object that you write in your everyday code is represented

by the JavaScript object, the object internally, inside the VM, and this also is the corresponding

shape object.

So shape defines or describes the layout, which properties the object has, and some

metadata, for example, the offset, where to find the value in memory.

You might think why do we need this shape, right?

Why not put all description of the properties on the object itself?

And the reason is memory save.

So, if we have two objects, on 1,000 objects, right, there's no need to describe the layout

every single time.

We can describe the layout only once, and then link this object to the shape that describes

the layout, right?

In this way, we only describe the layout once, even though we have, I don't know, potentially

millions of objects in memory.

But then, it creates a problem.

What if we want to add an extra property?

Now we want to extend the object A. We want to introduce the new property "W".

Well, we need to introduce a new shape.

We cannot add the W property to the original shape.

Because it would mean that the other object, the object B that points to the same shape

has this property, which is not true.

We need to introduce the new property and then the new shape.

Then we update links.

The object now, the object points to the new shape.

The same thing happens if we introduce another property we create one more shape.

And so, in fact, we end up with something called Transition Chains.

And it means that, when you try to access the property, for example, X, the original

property on the A object which points to the button on the chain.

It needs to go through every single property upwards and will until it finds the shape

that describes the property.

Okay?

You can imagine that, if you add a lot of properties in different places and modify

object shape, you will have a transition shape potentially with hundreds of transitions.

And so, every single time when you access a property, the virtual machine has to go

through all that process to figure out the shape that describes the layout and memory

of that and retrieve that information.

So a technique that V8 uses is to make that process faster.

The idea is simple: the ... is the main word here.

Every single JavaScript function is represented internally by the object called closure.

This is where the virtual machine caches some information about the function, which objects

are used to add parameters to this function, and the other information.

And feed the vector, and this is the cache.

This is where the virtual machine will cache some information.

So let me give you an example of how it works.

Suppose we are calling the function Get X and passing in an object with the X property.

The virtual machine figures out the shape for this object, right, and then what it can

do is that it can cache the shape of the object, and then the property, right, because we are

getting access to the X property, and it can couch the offset, right?

So the next time when we execute this function and pass in an object that has the same shape,

the virtual machine can only compare the shapes, and, if they match, there's no longer need

to figure out the shape.

You can just take the cache value from the offset and use it to resolve the value in

the memory.

And what it also does is it defines the state of the function, and the state there can be

three types of states: monomorphic state, monomorphic property access, and polymorphic.

In this case, it's monomorphism because it - it's monomorphic because it has been called

with one type of shape.

Polymorphic is when a function has seen four types of shapes up to four times, and megamorphic

is when you've been passing objects of different shapes, more than four types of shapes.

It's important that you pass objects of the state to one function so the state remains

monomorphic.

I read the comment that monomorphic property access can be up to 100 times faster than

megamorphic.

If you take into account this 10,000 times of access during each change detection cycle

that can happen several hundred times a second, you can imagine the kind of impact monomorphic

property access can have on the speed.

So frameworks use this to create - actually, what they do is they want to enforce this

function that takes these nodes, it uses the same shape, same hidden class for fibre and

view nodes, and that makes property access monomorphic.

You can have HTML elements, child opponents, and if you follow object-orientated programming

principles, you would create different classes for different elements.

These frameworks actually merge everything into one data structure, one class, with all

set of fields and they use one tag filled to distinguish between types of node.

This is the code from the React framework.

This is a function that is executed for every single DOM element, so potentially thousands

of times during each cycle, and you can see here that they try to distinguish by tag,

and then run the corresponding logic.

Okay, so that is monomorphism.

Now, let's talk about bitfils.

This is the other things that both frameworks happily used.

Bitfils is a low-level concept.

Those who have programmed with C++, for example, know this data structure, and bitfils is just

basically an array of bits - zeros and ones.

You can define a bitfil today in JavaScript, type OB prefix in console and you'll get the

binary fill.

Now React uses bitfils to en code side effects.

Side effects in React are basically just operations that the framework needs to do on DOM elements,

maybe place an element in the DOM, update tags, remove element, and, instead of having

an array of strings, for example, that define operations, they just assign places, and say

that, "Okay, the third bit is the update operation."

So, if the bit is one, I know that I need to update task.

If the bit is zero, it means that there is nothing to do here.

And I found that when I was debugging React, I'm sitting with a debugger, and I'm following

the spun element, and I've just updated the tag on the spun element, so I'm trying to

figure out what changes it will have.

So the effect tag is this effects filled, and it's a bitfil, so right after the render

face when it has process changes, the number, the value, is four, and, because it's a bitfil,

it's binary, so I converted it into like - here, it is actually the decimal, but I know it's

binary, so I converted it to binary and I got 100.

If you explore the fill, you can see it's a third bit, and that's exactly what I expected.

React encoded the update operation, so later - for example, here, when the function update

hosts the facts, it's executed, so, React will check every single bit and see what kind

of operations it needs to perform.

For example, update will up date the tags.

Now, you might be looking at that and think to yourself, "Well, why bother?"

This is okay, but it's still too low level, but there are a number of benefits, and advantages

that bitfils have over other types of data structures.

For example, with bitfils, there is no need to allocate memory for JavaScript objects

and shapes, so the virtual machine can save a lot of space, and because there is no shapes

and JavaScript objects, there are no references, it means that the garbage collection is a

lot simpler.

You know, you figure out the dependency graph and know which objects are safe to remove.

With the bitfils, it's one instruction to the processor to clear the contingent memory,

and that's it.

With the bitfil, it's a smaller contiguous memory usage and allows for fast access for

a single bit.

It's one twice operator, and that's it.

So that is bitfils.

They're used by both Angular and React.

The last date structure is bloom filters.

It's an interesting data structure.

This data structure is designed to answer one simple question: is it element in the

set or not?

Well, you can use an array, of course, and just go over each element, make a comparison

and figure out whether there is an element in the set or not.

It's quite long.

You can imagine you have one million objects, you need to go through every single one, and

it's pretty long.

Well, bloom filters allows you to do that with just one operation.

I show you how to do that.

What is good about bloom filters is you can get two types of answers - yes or no - and,

when you get the answer no, it means the element is definitely not in the set.

But when you get the answer yes, it's not actually yes, it's maybe.

The probability varies.