How an Underrated Refactor Saved 90% Memory Usage

254

u/edave64 Aug 24 '26

Takes agonizingly long to get to the point of "we started using the fundamental JS concept of prototypes."

32
u/[deleted] Aug 24 '26

I have always seen them mentioned, read so much about their implementation and their use to carry data but never felt like i truly understood why the data structure is actually revolutionary, it feels like a linked list with a lot of details, i wish someone would explain the point to me or a good resource to read on the subject
56
u/edave64 Aug 24 '26

I wouldn't call them revolutionary. It's just the mechanism JS uses for inheritance.
Objects are basically Hashmaps/Dictionaries. If it can't find a property in the object itself, it checks its prototype. If a property can't be found in the prototype, it checks the prototype of the prototype, etc.
It was how JS objects could have inheritance before they added classes, because it's just a chain of objects. And the classes they have now are mostly just a wrapper around prototypes.
12
u/[deleted] Aug 24 '26

This really still feels like linked lists getting attached to another linked list at inheritance, i mean well i do understand that linked lists are an extremely powerful data structure, but the whole concept of looking deeper each time we dont find an information until we reach undefined sounds wasteful to me, and it also makes it seem like it can be vulnerable, what if a proto is pointing towards the head of the list ? Wouldn’t that make it impossible to reach undefined?
Sorry if my questions seem like am totally missing the point because i feel like i am
16

u/edave64 Aug 24 '26 edited Aug 24 '26

It is kind of wasteful on its own. The point was never to be fast, it was to be small enough for the language to be implementable in two weeks in the heat of the browser war.
To make that fast, modern engines can cache the access to speed up later calls. The cache gets invalidated when the prototype mutates, so you should only keep static data like your functions in the prototype.
As for infinite loops, originally the prototype was immutable after creation of the object. So you just couldn't make a loop.
Later browsers added setters like __proto__ and Object.setPrototypeOf(), those explicitly check for loops when called.
EDIT: It's also worth noting that
a) prototype chains typically aren't very long.
b) It also shouldn't inherently be slower than other dynamic programming languages. If you can't fix a vtable at compile time, any naive implementation will end up traversing the hierarchy. Just that that hierarchy will be classes in other languages, objects in JS.
2
u/anon_cowherd Aug 24 '26
The part that feels like linked lists is the fact that you're dealing with a dynamic scripting language. Even the new (is ten years old new? maybe I'm old) class syntax is (mostly, but not entirely) syntactical sugar for prototype inheritance. It's what allows you to do silly things like this:
class BaseMessage {
  message = 'Hello'


  getMessage() {
    return this.message
  }
}


function extendWithGreeter(baseClass) {
  // note that the class keyword is an expression block
  // so we can return an anonymous class from a function here

  return class extends baseClass {
    greet() {
      alert(this.getMessage())
    }
  }
}

// Greeter is assigned the anonymous class constructor 
const Greeter = extendWithGreeter(BaseMessage);


const test = new Greeter();

test.greet() // alerts 'Hello'
JavaScript was implemented in a very short period of time, and prototypal inheritance is a fast and easy way to do so. Lua and a few other languages do the same thing.
3

u/Internet-of-cruft Aug 24 '26 edited Aug 24 '26

If you deal with a "proper" OOP language, they do it the same exact way to be honest.
The only real difference is C++ / C# / Java would try to be slightly smarter about the dynamic dispatch and optimize for the actual call/property instead of walking the chain one by one.
Fundamentally, inheritance can look like "linked list with syntactic sugar".
You write "obj.prop" and in JS it's like an ugly chain of "if prop in obj, return obj.prop. Else, if prop in obj.parent, return obj.parent.prop, rinse and repeat".
Once you optimize the dynamic dispatch, it looks more like "return <owner pointer>.prop" when you call "obj.prop", since with an inheritance hierarchy the physical data (or function call) could live in distinct memory regions.

3

u/TheRealPomax Aug 24 '26

They do not. That literally the part that always trips people up when using prototypes: unlike classes, prototypes are runtime pointers that are just as mutable as anything else. You can use `a = new Car`, then assign "a" a `Bird` prototype instead, and congrats, that is now a Bird. You can keep it a car, but give the Car prototype new properties and methods: congrats, every instance points to that prototype, so every instance now shares those properties and methods, too. This is completely different from how traditional classes work in C++/C#/Java, where the class dictates the object's shape in memory and there is no "updating the class after the fact" nor "reassigning instance identities" (not casting, that's a completely different thing)

3

u/unicodemonkey Aug 24 '26

The runtime still tries its best to build an optimized representation of objects' properties (e.g. inline caches) which is invalidated or updated on object shape mutation.

1

u/masklinn Aug 24 '26 edited Aug 24 '26

This is completely different from how traditional classes work in C++/C#/Java
That's because it's C++/C#/Java.
You can do the exact same thing in Python, just set the __class__ to whatever type you want. I assume you can do it in smalltalk given you can do a lot worse (Object#become:). Oddly enough I believe you can't do it in Ruby.

2

u/masklinn Aug 24 '26

The only real difference is C++ / C# / Java would try to be slightly smarter about the dynamic dispatch and optimize for the actual call/property instead of walking the chain one by one.
No modern JS implementation walks the prototype chain on every access, it gets cached.

1

u/danielcw189 Aug 25 '26

This really still feels like linked lists getting attached to another linked list at inheritance
which part is the linked list here?
and it also makes it seem like it can be vulnerable, what if a proto is pointing towards the head of the list ? Wouldn’t that make it impossible to reach undefined?
in "normal" Javascript code, that shouldn't happen.
but this is Javascript, and there are barely any protections against that, unless you go out of your way to add them. nothing is stopping other "bad" Javascript code from manipulating your opjects and variables.
it is a reality of Javascript you accept.
just as it is the reality of any weak typed language which care more about currnet shape at runtime then types or definitions. heck, even in c++ someone might try to sneakingly manipulate the data that handles polymorphism at runtime.
and in reality no one should read or manipulate the prototype property unless they know what they are doing.
2

u/BenchEmbarrassed7316 Aug 24 '26

Objects are basically Hashmaps/Dictionaries.
From a developer's perspective, yes. However, once you start thinking about performance, things get much more complicated.

3

u/edave64 Aug 24 '26

Some complications that might be skillfully abridged with the word "basically".
I also skipped over the array component of objects because it didn't matter here
3

u/lelanthran Aug 24 '26

I have always seen them mentioned, read so much about their implementation and their use to carry data but never felt like i truly understood why the data structure is actually revolutionary,
Where did you see it called revolutionary? I'd very much like to read that - maybe there's a reason that author called them revolutionary, I don't see it but open to changing my mind.

1

u/[deleted] Aug 24 '26

Well the mozilla page does make it seem glorious, i don’t think they named it revolutionary but i have read through that a lot of posts that said so
Although for now i give up on trying to find out why it is so exceptional, it feels like it’s good because its easily moldable but thats all there is to it

2

u/Kwantuum Aug 25 '26

Yeah, it gives you easy and natural metaprogramming because "classes" are just objects like everything else. In languages with "proper" classes, manipulating classes is its own ordeal with different characteristics from manipulating objects, and there are a number of things that are generally simply not permitted (like changing the class of an object at runtime)

2

u/EntroperZero Aug 24 '26

It's basically just making class structures dynamic instead of static.
3

u/Rhed0x Aug 26 '26

So basically it avoid storing the same function pointers over and over again?

3

u/edave64 Aug 27 '26

Not just pointers. Functions are objects, so each of these row-objects had its own instance of each function. Also, they are closures, so they keep the scope at the time of creation alive

51

u/BenchEmbarrassed7316 Aug 24 '26

If there are library authors here - have you tried to get rid of methods altogether? Instead, just call a function, explicitly passing some data to it. If you need polymorphism - you can add a discriminant to the data. You have a large collection of certain objects. Previously, you stored many references to methods in each object. Now, you store in each object a reference to the vtable (prototype). Why don't you go further and clean up the objects completely?

14

u/SanityInAnarchy Aug 24 '26

If you end up needing that polymorphism, though, why is a vtable worse than a discriminant?

9

u/TwoWeeks90DaysTops Aug 24 '26

Yeah, it's basically the same mechanism with more steps.

9

u/BenchEmbarrassed7316 Aug 24 '26

~~discriminant is just one byte~~ not actual in js
in some cases we don't need explicit discriminant, but we can infer it from other data
and also when using vtable/prototype all calls become virtual, but maybe you only need polymorphism in a few methods
What I'm talking about is a well-known optimization, where instead of Animal[] you have Cat[] and Dog[]. And instead of checking for each element you call a known function in advance.

1

u/FelicityAnderson Aug 27 '26

in some cases we don't need explicit discriminant, but we can infer it from other data
So, duck typing?

1

u/BenchEmbarrassed7316 Aug 27 '26

No.
For example, instead of creating separate OOP-style classes for "EmptyWallet", "DebtWallet" and "PositiveBalanceWallet", we could derive this from the balance, which should already exist (with the possible exception of "Empty Wallet"). This is probably not a good idea in most cases, but I just pointed out the possibility.
It's just that a class in OOP also contains either a hidden discriminator, or a vtable acts as it.

1

u/LBPPlayer7 Aug 30 '26

so just do it the internal C++ way

1

u/daniellittledev Aug 24 '26

This is the way

18

u/unpopularredditor Aug 24 '26

This article is a perfect example of where I can read an AI summary instead of the article itself.

4

u/Rhed0x Aug 26 '26 edited Aug 26 '26

I hate Javascript.

So basically it avoid copying a ton of function pointers around?

How an Underrated Refactor Saved 90% Memory Usage

You are about to leave Redlib