Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The cost of parsing JSON

v8.dev

Post reply on HN
Print view View original

271–280 of 308 posts

Re: The cost of parsing JSON

#271

Post by qtplatypus »

untog wrote: post #103
19ylram49 wrote: post #59

I mean, I get it, but I think performance is overrated in this particular case; unless it’s a significant and/or very noticeable difference, stick to object literals, please. I’d probably fire someone if I started to see `JSON.parse(…)` everywhere in a codebase just for “performance reasons” … remember, code readability and maintainability are just as important (if not more).

> remember, code readability and maintainability are just as important (if not more). I don't know about that. Prioritising making your own job easier over the experience of all your end users feels like a much more fireable offense to me. In this particular case I'm still a little wary of it because it feels like it's optimising for a current implementation with no idea what the future performance implications might…

It depends. Say you spend 8 hours of dev work to save 1 second of processing time per call. It will take 28,800 calls until your time investment pays for.

This assumes the cost of dev time is equal to the cost of CPU time. In some cases the additional speed is going to return more value then the cost of the dev working. And other time the additional value of getting the product to market is going to win out.

Re: The cost of parsing JSON

#272

Post by diek »

lossolo wrote: post #197
nostrebored wrote: post #182

Earlier quoted context omitted.

Thank you for the excellent explanation! I think of js entirely from a node.js perspective where I conceptualize it as an async task. Is this also wrong?

> Is this also wrong? Yes, node.js javascript runtime is based on V8, the same that runs in Chrome. Javascript is single threaded so anything that is not I/O bound will block the main thread. If you don't want to block the thread becasue you have long running calculation/parsing task, then you can use worker threads[1]. This will run your task in separate thread and not block the main one. [1] https://nodejs.org/dist…

Fun detail: node internally will use thread pools to do CPU-intensive tasks that would normally block the main thread.

For example: https://github.com/nodejs/node/blob/master/src/node_crypto.c...

I generally use that as an example when explaining to people why Node isn't a great fit for a lot of workloads. They have to use these features internally, but you as the user with a CPU-intensive job don't have access to those features.

Re: The cost of parsing JSON

#273

Post by other_herbert »

t1amat wrote: post #237
adimitrov wrote: post #206

Earlier quoted context omitted.

> Part of me still thinks that he just wanted to learn/use the JNI and that project seemed like the perfect target. Lol. As a dev who sometimes goes off chasing wind mills, that's 99% of the reason why I do it. I find something nice to tinker with, and when my brain goes "ooh, shiny" I stop giving a shit about anyone's bottom line. To be fair, it usually turns out for the better for the project and its code base! But…

> Companies should be willing to take these kinds of informed risks in order to improve their employees' ability, and therefore the quality of their product. Perhaps they should be willing, but your description of this distraction does not including informing the Company and allowing them to determine whether it’s a risk they are willing to accept. You decided for them because you didn’t want to receive the answer “n…

I think i work in a similar manner to the gp.. It's transparent to the org... It's not I'll head down this path or investigate this _or_ get my work done.. It's an _and_ situation. Sometimes the rabbit trail is the best thing sometimes you just have to get the thing done... Either way it's still getting done

Re: The cost of parsing JSON

#274

Post by clinta »

Klathmon wrote: post #62
Tade0 wrote: post #48

I think this fragment catches the spirit of this piece: 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. Although it may still not be worth it. At work I have this hand-rolled utility for mocking the backend using a .har file(which is a JSON). I use it to reproduce bugs found by the testers, who…

I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1]…

Is that relevant when comparing parsing json with parsing literal objects? I don't know much about JavaScript engines but I'd expect that parsing literal objects in code is also blocks the main thread.

Re: The cost of parsing JSON

#275

Post by kllrnohj »

manfredo wrote: post #261
kllrnohj wrote: post #257

Earlier quoted context omitted.

> These benchmarks indicate better protobuf performance [1]. We're exclusively talking about cold start performance here. Single, one-time object creation. Hence why JS syntax parse is the dominate factor and not execution performance. Those benchmarks are not that, they are hot performance. That's a completely different thing. > Not to mention end to end load time (which is probably what people are usually trying to…

What is the "completely different thing" you're referring to here. Between: 1. Having a static JSON string, and decoding that string. and 2. having a static blob, and using protobufs to decode that blob. these two things accomplish the same thing. I'm not sure why you seem to think one is a "cold start" and the other is "hot" - they're both "single, one-time object creation". The former is going to be parsing ints an…

Are you including the cost of loading protobuf itself? You seem to be basing your argument on an assumed already present & loaded protobuf library.

You need to benchmark starting from nothing at all. Your link that you seem to be basing this off of has a loaded and fully JIT'd protobuf. That's not the start state.

Re: The cost of parsing JSON

#276

Post by [deleted] »

pushpop wrote: post #186
TylerE wrote: post #157

Earlier quoted context omitted.

Some of us can’t just lost our health insurance on a whim.

Thankfully most other developed country’s healthcare system doesn’t penalise individuals quite so significantly as the broken system you Americans keep voting for. I’m not saying the UK or other European counties have the perfect healthcare systems either but at least we aren’t tied to a job we don’t like because losing our company’s health scheme is too scary to consider.

[deleted]

Re: The cost of parsing JSON

#277

Post by nojvek »

Klathmon wrote: post #62
Tade0 wrote: post #48

I think this fragment catches the spirit of this piece: 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. Although it may still not be worth it. At work I have this hand-rolled utility for mocking the backend using a .har file(which is a JSON). I use it to reproduce bugs found by the testers, who…

I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1]…

If you really need to work with large data files 1mb+. Json is a terrible format. You should look into flat buffers. It’s like having indexed json where there is no parsing cost. You can have millions of rows and nested objects and it will only read the bytes it needs.

It is length prefix encoded format so it’s pretty safe to work in a streaming manner too.

Re: The cost of parsing JSON

#278

Post by nojvek »

Klathmon wrote: post #81
nostrebored wrote: post #72

Earlier quoted context omitted.

Why not just use promises? side note: legit question, I don't do web/app dev

Because JSON.parse blocks the thread it's in, and JS is single threaded [1]. So even if you put it behind a promise, when that promise actually runs, it will block the thread. In essence, using promises (or callbacks or timeouts or anything else like that) allows you to delay the thread-blocking, but once the code hits `JSON.parse`, no other javascript will run until it completes. And since no other javascript will r…

Another trick most people don’t realize is that not only is the fetch api is asynchronous but response.json() does the conversion in a background thread and is non UI blocking.

If you have a large json object. You can use the fetch api to work with it. If you need to cache it, use the cache storage api. Unlike localStorage which will freeze the UI, cache storage wont.

It’s slightly slower since it needs to talk to another thread but who cares as long as the UI is responsive to do other things.

Re: The cost of parsing JSON

#279

Post by nojvek »

ssalka wrote: post #262
est31 wrote: post #235

Earlier quoted context omitted.

Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines, you could make the case for usage of binary formats like protobuf. IMO this trend of piling on technology after technology to handle bloat instead of designing websites to be lean is wrong but it's certainly the direction we are walking into. Websites will become even more opaque and compl…

>Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines Any idea what the timeline for such changes could be? Personally I'd welcome the possibility of compiling complex web apps down to WASM, but I can't see the things you mention happening any time soon

You don’t need webassembly. We already have typed arrays to represent binary data and do fast slices.

That’s essentially what flatbuffers is. Slightly larger than protobuf but insanely fast to parse since it doesn’t need to scan the whole file. It’s both memory and CPU efficient. Netflix uses it in their app because TVs can be low powered devices.

That’s why Netflix feels so much lighter than amazon, hbo or Hulu. They all freeze my Vizio TV but Netflix is smooth.

https://github.com/google/flatbuffers

Re: The cost of parsing JSON

#280

Post by nojvek »

rolltiide wrote: post #266
est31 wrote: post #235

Earlier quoted context omitted.

Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines, you could make the case for usage of binary formats like protobuf. IMO this trend of piling on technology after technology to handle bloat instead of designing websites to be lean is wrong but it's certainly the direction we are walking into. Websites will become even more opaque and compl…

I'd like to see protobuf take off, but we're talking 2025, 2028?

https://google.github.io/flatbuffers/ Is what you want in the browser.
Post reply on HN