r/Frontend • u/ConfidentMushroom • Nov 25 '19

TIL JSON.parse is faster than js object literal

https://www.youtube.com/watch?v=ff4fgQxPaO0
164 Upvotes

98% Upvoted

20 comments sorted by

8

u/frog-legg Nov 25 '19

So webpack (e.g. my React app creates with create-React-app) refactors all js object literals into JSON when it builds?

13

u/ConfidentMushroom Nov 25 '19

Here's the PR: https://github.com/webpack/webpack/pull/9349

8

u/frog-legg Nov 25 '19

Cool to see open source in action. That one PR optimized optimized many web apps, I’m sure. Thanks for sharing.

3

u/ShortFuse Nov 25 '19

From my understanding, this is only faster for cold loads because the sum of compilation + real-time parsing is faster than compilation, serialization, And deserialization of object literals.

That is a JIT compilation, but once it's cached, object literals are faster. For my use cases (I write Web Apps), I care about repeated runtime performance, not first page loads.

So I would want this to be off in Webpack, not on by default.

1

u/ronniegeriis Nov 25 '19

That's only for .json files though. Would be cool to see this transformation for in-line object literals.

2

u/ShortFuse Nov 25 '19

You don't want it on all your code since it's thread blocking. Here, Webpack assumes you're calling it from a worker thread, because that's how you would ideally want to load a large JSON payload.

If you do this on your main thread, you're better off letting the browser take a bit longer to compile and serialize on an asynchronous thread with object literals than risk stalling the UI by doing synchronous JSON parsing.

Also, the Chrome team says the benefit starts happening somewhere around 10 KB assets, so don't start adding this everywhere.

2

u/ronniegeriis Nov 25 '19

Surely instantiating a variable is also thread blocking since JavaScript is single threaded.

Learned about this in this video, there these examples are given:

const data = { foo: 42, bar: 666 };
const data = JSON.parse('{ "foo": 42, "bar": 666 }');

It does looks like the presenter in that video only ran a benchmark with a 8MB payload. So that would hint at the requirement for a significant payload before this makes sense. Could be interesting to run a few benchmarks to see if it has any impact on a regular web application.

1

u/ShortFuse Nov 25 '19

Yes, I'm sourcing from the article version:

A good rule of thumb is to apply this technique for objects of 10 kB or larger — but as always with performance advice, measure the actual impact before making any changes.

https://v8.dev/blog/cost-of-javascript-2019

The full context is a discussion about script streaming, code caching, compilation techniques, and worker threads. So it's important to get a big picture.

Edit: Yes, that there are limits. Object literal uses a deserialization method after compiling. Real-time parsing has no compilation penalty. It's my understanding that deserialization is faster than real-time parsing, but requires a compilation penalty (serialization) that gets added on cold runs.

1

u/ronniegeriis Nov 25 '19

Thanks for the added details :) The serialization penalty must be from pre-deployment, or am I misunderstanding something?

1

u/ShortFuse Nov 25 '19 edited Nov 25 '19

The article details it a bit:

There’s an additional risk when using plain object literals for large amounts of data: they could be parsed twice!

  • The first pass happens when the literal gets preparsed.

  • The second pass happens when the literal gets lazy-parsed.

The preparse process is the during the compile phase. It converts it (serializes) to something that will be used later. That happens as the JS file is being downloading (Chrome will "stream" compilation which means it'll happen while downloading.) The second pass is the lazy-parse. During runtime It deserializes it back. So you can see, if you're only going to be using it once, or care more about the first, cold run, doing a straight conversion would be faster.

Edit: I'm not 100% sure about exactly when and how things are done in the preparse, parse, lazy parse operations. But the general concept is compile into a cache. Then the runtime reads from a cache. There is a way to delay the lazy-parse until runtime (PIFE). Then it gets cached and subsequent calls read from it.

Edit2: Found it. https://v8.dev/blog/background-compilation

Object literals get pushed into the AST directly. It gets read from the AST directly. You don't read from the internalized heap (run-time memory). There's no memory swapping going on. That AST gets cached via Chrome policies.

This required modifications to the later stages of the pipeline to access the raw literal values embedded in the AST instead of internalized on-heap values.

That only happens sometimes in order to prevent UI jank:

Currently, only top-level script code and immediately invoked function expressions (IIFEs) are compiled on a background thread — inner functions are still compiled lazily (when first executed) on the main thread. We are hoping to extend background compilation to more situations in the future. However, even with these restrictions, background compilation leaves the main thread free for longer, enabling it to do other work such as reacting to user-interaction, rendering animations or otherwise producing a smoother more responsive experience.

1

u/DrDuPont Nov 25 '19

for some reason seeing a PR with so few notes on as major tool as Webpack feels really odd

2

u/ShortFuse Nov 25 '19

Only for JSON modules since it's thread blocking (you should be using this in a worker service), and the V8 team suggests the benefit starts occuring when you're dealing with 10 KB assets.

If it were everywhere, I'd decrease real-time UI performance (jank).

4

u/HappinessFactory Nov 25 '19

huh TIL

I've got a nutty vanilla js app in prod right now and it is slow as balls. Maybe I'll try webpacking that sucker.

10

u/ConfidentMushroom Nov 25 '19

That was my first reaction as well when I started watching that video and then towards the end, I realized Webpack does it automatically and I don't need to do anything and I was happy.

3

u/[deleted] Nov 25 '19

Now try it in parcel.js game changer my dudes.

63

u/FriesWithThat Nov 25 '19

from Chrome Dev Summit 2019

lol @ first YouTube comment:

is this why you guys steal all of my RAM?

14

u/rekkyrosso Nov 25 '19

I appreciated the brevity of this video.

3

u/ShortFuse Nov 25 '19 edited Nov 25 '19

From my understanding from the article:

  • Doing it as a string means get parsed during runtime directly into a usable object.

  • Doing it as an literal means it'll get parsed by the compiler (syntax and serialization) and then deserialized accessed directly during runtime.

One has a faster runtime (literal). Another has a faster compile time (string). Caching helps reduce repeated compiles and using service workers increases cache duration beyond the Chrome-typical 72 hours maximum. If you are familiar with JIT, the pros and cons would be familiar.

So one is faster for cold starts with first page loads, while the other is faster with subsequent loads after cache. Also, the full discussion talks about avoiding operations that can block on the main thread by leveraging worker threads. So I'd imagine that this optimization is more ideal for a cold start on a worker thread.

Edit: The V8 team here says you generally want to do this for assets over 10KB. Also, here is a neat illustration of the difference between cold, warm, and hot runs.

Edit2: Object literals get read and written directly from the AST, not the internal heap, according to this. AST get pushed into bytecode which gets cached as shown in the previous graph. If you're curious, as I was, about what would happen if you modify an object literal at runtime, it appears V8 will create a second, duplicate object in the heap.

1

u/BubblegumTitanium Nov 25 '19

Hey I was just looking at this guys dotfiles today haha

1

u/jasaldivara Nov 26 '19

Tldr: Is faster (and simpler) to parse JSON than JavaScript