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

111–120 of 308 posts

Re: The cost of parsing JSON

#111

Post by Sephr »

IggleSniggle wrote: post #12

Commenting the security issue from the end of explainer for visibility. I’m having flashbacks to the Java serialize vulnerabilities from a couple years ago. ECMAScript and JSON do not have the same set of escape characters: ``` Note: It’s crucially important to post-process user-controlled input to escape any special character sequences, depending on the context. In this particular case, we’re injecting into a tag, s…

Why would you ever be escaping HTML in client-side JS? You should be using appropriate DOM APIs (which don't include innerHTML) to manipulate the document.

Re: The cost of parsing JSON

#112

Post by SirensOfTitan »

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).

> I'd probably fire someone if I started to see `JSON.parse(...)`

I've had the privilege of working in organizations that consider mistakes to be the cornerstone of resilient systems. Because of that, comments like this scare me, even when intentionally hyperbolic. More so, if the product works well and is being maintained easily, why would you micromanage like that? Sounds like a minor conversation only worth having if the technical decision is having a real impact.

Thomas J. Watson:

> Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?

Re: The cost of parsing JSON

#113

Post by manfredo »

ricardobeat wrote: post #86
Klathmon wrote: post #68

Earlier quoted context omitted.

They say in the linked article that this should only be used for objects about 10kb and larger. I'd argue that if you have 10kb or larger object literals in your codebase, you are already missing the mark on readability and maintainability in some ways.

Where you'll usually find this: - exporting data from server to client for initialization - localization data - environment variables (feature maps, configuration etc) - preloading datasets for graphs/tables

If it's exclusively going to be used for heavyweight operations like these, it's probably better to benchmark against protobuf decoding. I guess using JSON has a "works out of the box" appeal, and doesn't require defining any protobuf schema. But personally I don't see defining proto files as too prohibitive in terms of development cost.

Re: The cost of parsing JSON

#114

Post by yiyus »

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…

The graph in the article includes results for other engines too, not only V8.

Re: The cost of parsing JSON

#115

Post by ChrisArchitect »

this came up at a conference I was at last week (FITC WEBU/Toronto) in a talk by Houssein Djirdeh from Google entitled "What's New in Speed at Google?"

Someone asked if it was recommended everyone start refactoring their code to have this change and he replied it would depend on size of project/code etc..as the performance benefit might not be there for huge things, but in some smaller cases it could definitely be a plus.

Re: The cost of parsing JSON

#116

Post by penagwin »

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]…

I'm asking purely out of curiosity - what was the content of such a large JSON object?

Re: The cost of parsing JSON

#117

Post by ZephyrP »

IggleSniggle wrote: post #12

Commenting the security issue from the end of explainer for visibility. I’m having flashbacks to the Java serialize vulnerabilities from a couple years ago. ECMAScript and JSON do not have the same set of escape characters: ``` Note: It’s crucially important to post-process user-controlled input to escape any special character sequences, depending on the context. In this particular case, we’re injecting into a tag, s…

JSON is a syntactic subset of Javascript in ES2019 [1].

https://github.com/tc39/proposal-json-superset

Re: The cost of parsing JSON

#118

Post by willis936 »

flabbergast wrote: post #100
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).

> I’d probably fire someone if I started to see `JSON.parse(…)` everywhere in a codebase just for “performance reasons” … Yep, and I'd fire you for doing that! There are better ways to manage instead of showing off your authority. Oh, and by the way, would some JSON.parse statements for performance be the worst thing in your codebase(s) you guess? I mean, I cannot believe that would be the worse in your codebase. Als…

Would you also fire yourself?

Re: The cost of parsing JSON

#119

Post by dkersten »

ricardobeat wrote: post #86
Klathmon wrote: post #68

Earlier quoted context omitted.

They say in the linked article that this should only be used for objects about 10kb and larger. I'd argue that if you have 10kb or larger object literals in your codebase, you are already missing the mark on readability and maintainability in some ways.

Where you'll usually find this: - exporting data from server to client for initialization - localization data - environment variables (feature maps, configuration etc) - preloading datasets for graphs/tables

None of these need readability though (or are particularly readable to begin with, regardless of if object literals or parsed).

Re: The cost of parsing JSON

#120

Post by Klathmon »

penagwin wrote: post #116
Klathmon wrote: post #62

Earlier quoted context omitted.

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]…

I'm asking purely out of curiosity - what was the content of such a large JSON object?

It was a carton scanning app, so basically a massive array of objects (carton data) which were needed so the app could function and route cartons and validate deliveries entirely offline. Due to some unfortunate limitations from our clients and some edge cases, we couldn't filter down the data on the server ahead of time. So we ended up having to keep that massive amount of data on the device, and at the end of the day 95% of it would be unused, but we wouldn't know which 95% until the device was already offline.

It was a system where the goalposts moved many times during the development. If I were to do it again, I wouldn't use JSON, but after having the goals change a few times and then having the original server-side components get co opted to work on other projects, it was hard to justify the time that would be spent switching to a different, more appropriate wire format.

Post reply on HN