Javascript Classes v. Closures (2/3)

Performance

Richard Marmorstein
Jun 1, 2017 · 5 min read

Overview

This is part 2 of a series of posts where I explore the tradeoffs between Javascript classes and the closure pattern (known frequently also as the factory class pattern), two patterns that can be used as substitutes for each other. The series is in three parts

  1. The closure pattern is more lintable than the class pattern.
  2. The class pattern tends to perform better than the closure pattern.
  3. The class pattern is more monkey-patchable than the closure pattern.

I will compare both memory efficiency of the two patterns, and then CPU efficiency. But first:

Background: The Object Prototype

To appreciate this post, you should be familiar with Javascript’s object prototype. I recommend this very detailed overview if you are not. Salient details:

  • You can make multiple objects with the same prototype using the new keyword.
  • You can put methods on this prototype.
  • You can call those methods as if they were attached directly to the object, and when you do so, inside the body of the method, this will refer to your object.

This snippet which uses a class:

can be roughly imagined as

Whereas this snippet that uses a closure

can be roughly imagined as

Memory Efficiency

Notice that the ‘rough imagining’ of the class implementation only has one function literal, whereas the ‘rough imagining’ of the closure implementation has two different function literals. Similarly, only one function will live in memory while the class version of the program is running, but two separate functions will live in memory while the closure version of the program is running. Classes “save space” by reusing methods across different instances of the class.

Why not test this empirically, by running some contrived code on my laptop? Here is the contrived code:

and its closure-based analog:

Now let’s run them!

Image for post
Image for post

Looks like the closures version used substantially more memory. That was to be expected based on the analysis above: “classes save space by reusing methods across instances”. Why the boost in speed though?

CPU Performance

It turns out this is a little more complicated a question. I recommend reading a back-and-forth between Marijn Haverbeke (author of Eloquent Javascript) and Vyacheslav Egorov (a V8 developer at Google).

First, as Haverbeke muses, there are some reasons to expect that closures might be quicker. In principle, they are simpler, in a sense. The number of closed variables in the scope of a closure is fixed. They take up a fixed space in memory. Whereas, the number (and type) of properties on an object is not fixed. They can be changed at any time. So if you had many many instances of a closure, you might expect the runtime to be able to deal with them very efficiently, because it has stronger guarantees about their uniformity than it would if they were instances of a class.

I will admit I do not fully grok Egorov’s very technical response, but the understanding that I do get is, basically, v8 rocks at doing classes. Despite how you do not have a strict guarantee that instances of a class will be uniform, the runtime is nevertheless very good at sorting them into uniform “hidden classes” anyway, and taking advantage of any uniformity that does exist. So any uniformity advantage of closures is effectively negated.

Furthermore, the V8 runtime engine is able to optimize frequently called methods. Instances of classes share methods, so if you call the same method on a bunch of instances of the class, that method will be frequently called and V8 is able to optimize it and effectively use ‘inline caching’. For closures, on the other hand, each closure has its own copy of the method. So if you call the method of the same name on a bunch of instances of a closure — it’s not actually the same method. They are all different methods. So V8 won’t optimize it as effectively.

In principle, it’s possible, says Egorov, for V8 to be a little bit smarter and do static analysis on the code to perform some of these optimizations for closures when feasible. But — at least at the time of his writing — nothing like this has really been implemented.

In the meantime, classes tend to be more performant than closures both in terms of memory and CPU. Of course, in much code, performance is of lesser concern than readability and maintainability. But, since the two patterns are equivalent in many ways, the performance aspects may be something that tips the balance for you.

Make sure to stay tuned for the next and final post in the series. I’ll discuss how classes are more monkey-patchable — and thus sometimes more testable — than closures.

Update:

A previous version of this post contained a mistake which slightly biased the results against the ‘closure’ version. The code and the results have been updated to correct this. Great thanks to achen2345 of reddit!

I’ve made available a browser-based version of these examples, so that you can run the tests in your own browser and see how performance is affected. Let’s get those cows to mooing!


If you enjoy thinking hard about Javascript, consider joining our team of classy developers at Livestream.

Engineering@Livestream

Engineering Blog for Livestream.com

Richard Marmorstein

Written by

An autonomous generalized problem-solving and entertainment system, implemented chiefly in deoxyribonucleic acid, featuring a robust natural language interface.

Engineering@Livestream

Engineering Blog for Livestream.com

Richard Marmorstein

Written by

An autonomous generalized problem-solving and entertainment system, implemented chiefly in deoxyribonucleic acid, featuring a robust natural language interface.

Engineering@Livestream

Engineering Blog for Livestream.com

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store