Maxim Koretskyi

Transcript

Okay. 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.

Because of that, this data structure is called probabilistic, right? There is probability here. You might be looking at that and thinking to yourself, "Who needs a data structure that doesn't give you correct answer s?" This data structure is used most often when you expect the answer no most of the time. And this is exactly the case that I will present to you now. But first, I will show you how this data structure works, so each element in the set is encoded in a bitfil - one bitfils, or a few bitfils - you will have a hashing function that will take a value and produce some number.

For example, for John, if we run the function and we get the number 2, for example, we use the first letter and the code, for the letter, we will just use a binary or operator to set the second bit. And later, we will use the same function to get the number for John, but now we will use the B twice or operator to check if the John is here. You can imagine if the bit is not set, if it is zero, it means that John is not here. Now, where the problem is why, yes, it's not guaranteed. The problem is collisions.

If we use the same hashing function and we use, for example, the only first letter to figure out the number, we're passing John and Jane, they have the same first letter. Here we have a collision, right? We end up with the John being in the set and Jane not being in the set, but the hash function would produce the same value and we get a wrong result. So where does Angular use this? It uses in a dependency injection system. So the cornerstone of the dependency injection system is an injector.

It's a service, a container, where you can con figure the dependencies between services, and then the injectors responsible for instantiating them. Whereas most systems have only single injector called Global Injector, Angular has a hierarchical dependency injection, so, for the hierarchy of components, it creates an injector. For each component, you get an extra injector, so you end up with a hierarchy of injectors, and let's say the widget manager is provided in the top-most injector, or the bottom-most one requires on the widget. Angular would have to go through every single injector to figure out where exactly is this service, and only when it reaches the bottom-most injector it will be able to resolve the component. You can imagine it could take quite a while, for example, if every single injector has ten dependencies, ten services, it would need to go through every single one of them and do comparison which is a long time.

So what Angular does, it introduces a bloom filter for every single injector, and with bloom filter, as I showed you, it's one operation to know whether the service is in the set or not. As I told you, the answer is most likely to go to be no, to so here, no here, and the last, the top-most, the answer is maybe. If we get the answer maybe, then we can do our actual comparison and find the service if it is there. So that is bloom filter for you.

Okay, so here's a bunch of protocols that, if you're interested in that kind of flow-level details, I've written about reverse engineering, because I've reverse engineered webpack, other tools, change detection in Angular, and reconciliation in React. So here are the articles for you to check out. Also, if you want to learn more about this kind of topics, you can follow me on Twitter. I regularly write about some findings that I pick in these frameworks, and I've written about my journey, the article you can also read. So I hope that the knowledge that I've told you today that is awakened your curiosity to learn more about this kind of stuff, and I want you never to stop learning, and, by doing so, you will be able to reach new heights every day.

Because I want you all guys to be extraordinary engineers. Thank you for your attention, and good luck. [Applause].