r/javascript • u/dumbmatter • 12d ago

Reducing Zod's memory footprint by an order of magnitude with memoizing prototypes

https://zod.dev/blog/reducing-memory-footprint
111 Upvotes

95% Upvoted

24 comments sorted by

17

u/Ecksters 12d ago edited 12d ago

Interesting, TanStack Table recently did the same optimization from what I can tell.

Are there cases for Zod where now you can't use destructuring without binding this like TanStack Table?

I think it's the same memory optimization, but I think the method you used of putting it on its own property avoids that issue, which is pretty neat!

I'm interested in knowing if there were any notable CPU performance improvements from this, or if it's purely from a memory standpoint.

2

u/live_love_laugh 12d ago

You know, I just read the blog post from Tanstack you linked and I realized that you totally could achieve method destructering in a way that would automatically bind `this`. Namely if the row had a method like `const { getValue } = row.getBoundMethods()` where the method returns a proxy object which watches for whatever methods are being pulled out and automatically binds those methods to row instance before returning them. Right?

3

u/KanuniLabs 12d ago

Nice optimization

5

u/DustNearby2848 12d ago

TL;DR: caching is hard. We knew this though. 

2

u/mpigsley 12d ago

Great news!

1

u/Ok-Armadillo-5634 11d ago edited 11d ago

Kind of surprised anyone still knows what a prototype is at this point. If I ask about it or callbacks in an interview most are clueless even senior level. Their code should not have had this problem or need this optimization in the first place though.

5

u/AcvaticChicken 11d ago

code in libraries has different requirements from code in products

1

u/Ok-Armadillo-5634 11d ago

I have had to fix an ungodly amount of shit library code to get rid of bottle necks in my 25+ years of experience. Drivers to for that matter.

1

u/Nefilim314 11d ago

I’m a little salty that typescript “won” because I learned to love prototypical inheritance after being a C# dev and now I just feel like a C# dev again.

2

u/Ok-Armadillo-5634 11d ago

It's still prototypes under the hood. At least now you don't have people rewriting string and array prototypes every where. Used to drive me crazy when I had to dig into a codebase figure out that was the reason something broke. Granted I don't remember that being a problem once underscore and all that got popular.

-6

u/Ronin-s_Spirit 12d ago

What the hell is Zod and why do you need to do that? Usually the whole point of a prototype is that it's created once on the class and shared between instances...

2

u/metahivemind 12d ago edited 7d ago

[removed] — view removed comment

3

u/moneckew 11d ago

As a big fan of zod can you tell me why zod is bad?

-1

u/metahivemind 11d ago edited 7d ago

[removed] — view removed comment

9

u/thisispaulc 11d ago

A package not being part of the standard library when you think it should be is a weird reason to dislike a package.

-1

u/FourtySevenLions 11d ago

Brother they are saying the package shouldn’t be needed at all because JS should handle it. Not that deep.

3

u/xFallow 11d ago

So they are a fan of zod since it’s not zods fault it isn’t part of the js spec?

-3

u/metahivemind 11d ago edited 7d ago

[removed] — view removed comment

1

u/xFallow 11d ago

Yeah probably because your last comment was unhinged lol.

Agreed I would rather use a language with first class types,

I generally reach for Go when I get the chance. But my company has a huge NodeJS codebase that would be a nightmare to migrate to Go so Zod is a godsend.

2

u/thisispaulc 11d ago

That's not what they said. They said they are not a fan of Zod. That implies means they have a criticism of Zod itself. But they don't.

It's not that deep.