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

301–308 of 308 posts

Re: The cost of parsing JSON

#301

Post by manfredo »

ricardobeat wrote: post #293
manfredo wrote: post #281

Earlier quoted context omitted.

You can measure the impact on loading time, and the size of the protobuf implementation you're using probably has an impact on the threshold at which it becomes more efficient. I don't doubt that parsing a 500 character long JSON string is probably faster than loading a protobuf to do it instead. In fact, apparently this JSON parsing trick is only effective beyond 10K or so. But past a certain threshold memory bandwi…

You’re repeatedly missing the point. This is about optimizing startup time. The comparison should be: cost of downloading payload + runtime cost of parsing JSON Vs cost to download protobuf lib + parse and execute JS protobuf lib + download payload + runtime cost of parsing Specifically, the article talks about how parsing JS is more costly than JSON - this cost will apply to the protobuf library which certainly far…

> Specifically, the article talks about how parsing JS is more costly than JSON - this cost will apply to the protobuf library which certainly far exceeds 10KB.

I would suggest reading the links I posted. The minimal protobuf library, which is suitable for working with static decoding, is 6.5KB [1]. Again, you're right that the size of the protobuf library will be an important factor in dictating the scale at which it's more effective than JSON parsing but your sense of the factors is off - a light protobuf library doesn't reach 10kB let alone "far exceeds 10KB".

Furthermore, if your pages use the protobuf library already for other uses like decoding and encoding RPC messages then loading and parsing the protobuf library is basically free - you're going to be doing this anyway.

1. https://www.npmjs.com/package/protobufjs#installation

Re: The cost of parsing JSON

#302

Post by munk-a »

Gibbon1 wrote: post #248
munk-a wrote: post #220

Earlier quoted context omitted.

Assuming you are managing a dev (either through a lead role, seniority, or as a manager) you absolutely should shield team members from direct demands from up that chain - that's what most of your job is... Assuming the employee was acting within the rules you've laid out then the you should shield them and consider adjusting your rules to prevent a repeat - if, to contrast, your company has some CI tooling setup and…

> you absolutely should shield team members from direct demands from up that chain - that's what most of your job is The other part of your job is keeping your manager informed about subordinates that are being problematic. Up and rewriting a critical piece of infrastructure 'because' is problematic.

(I'm assuming that you mean that the other person is another subordinate to the same manager, rather than being someone subordinate to you)

It's a bit of a delicate balance. The golden rule is that Snitches get Stitches, but if someone is being unproductive with their time and your manager isn't aware of that fact then letting them know isn't a terrible idea. But it isn't your place to measure how your co-workers are accomplishing their tasks - assuming management isn't out to lunch then performance reviews should fall on their shoulders. Maybe your coworker cleared a rewrite with your manager and your manager was satisfied with the justification and decided that explaining the full reasoning would be a waste of time until the experimental phase was completed.

In theory good management should prevent you from feeling like you need to look over other people's shoulders, because that is their job. So if you are feeling that way you might want to talk to your manager about it, maybe they are bad at managing and are letting things slip through the cracks, maybe they find that allowing someone to experiment with a rewrite is worth the training time - it may be possible that you just need to talk it through with them and find more confidence in their management ability.

Re: The cost of parsing JSON

#303

Post by ricardobeat »

manfredo wrote: post #301
ricardobeat wrote: post #293

Earlier quoted context omitted.

You’re repeatedly missing the point. This is about optimizing startup time. The comparison should be: cost of downloading payload + runtime cost of parsing JSON Vs cost to download protobuf lib + parse and execute JS protobuf lib + download payload + runtime cost of parsing Specifically, the article talks about how parsing JS is more costly than JSON - this cost will apply to the protobuf library which certainly far…

> Specifically, the article talks about how parsing JS is more costly than JSON - this cost will apply to the protobuf library which certainly far exceeds 10KB. I would suggest reading the links I posted. The minimal protobuf library, which is suitable for working with static decoding, is 6.5KB [1]. Again, you're right that the size of the protobuf library will be an important factor in dictating the scale at which i…

I currently work on a project using protobufjs. Our generated static classes are ~500KB and ~1.5MB, or around 140KB gzipped. The schemas are not that large, and this does not even include any network code (not part of protobufjs).

Re: The cost of parsing JSON

#304

Post by Sephr »

IggleSniggle wrote: post #283
Sephr wrote: post #111

Earlier quoted context omitted.

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.

I think you’ve missed the vulnerability. You can use appropriate DOM APIs all you want and be hit by a malicious escaper if you don’t serialize in the right way. At some point, your js is inserted into the document via a script tag. If you use the JSON parser to initialize your data more quickly, and your data has user input anywhere within it, then if you aren’t careful about encoding/decoding your string, the attac…

Hence why I said "You should be using appropriate DOM APIs"...

The appropriate DOM APIs don't take HTML strings in the first place. You shouldn't be passing HTML strings to JS.

Re: The cost of parsing JSON

#305

Post by Sephr »

tracker1 wrote: post #179
Sephr wrote: post #111

Earlier quoted context omitted.

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.

If the JSON itself contains strings with markup included, and you're injecting directly into a script tag in the HTML document. Though, if you're dealing with a typed object server-side and/or loading into a .js file request, it's less of an issue, if you aren't supporting html markup in the object to begin with. In my own use case, both are true.

Hence why I said "You should be using appropriate DOM APIs"...

The appropriate DOM APIs don't take HTML strings in the first place. You shouldn't be passing HTML strings to JS.

Re: The cost of parsing JSON

#306

Post by mark-r »

swish_bob wrote: post #299
mark-r wrote: post #184

Earlier quoted context omitted.

I've found that the readability of fast code vs. slow code is often negligible - certainly it is in the specific example under discussion. I prefer to make a habit of using faster idioms in that case, so that when speed does matter I'm already covered. I don't consider that premature optimization.

Except it isn't, because most of your developers will be using an environment that includes syntax highlighting and probably some linting. Except within string literals. Code inside string literals is less readable and more inclined to be wrong/buggy.

I was arguing the general principle of not being afraid of premature optimization, not this particular example. You make good points.

Re: The cost of parsing JSON

#307

Post by monkeydreams »

microcolonel wrote: post #292
tabtab wrote: post #240

Earlier quoted context omitted.

Don't tell people that. Those who believe climate change is a hoax will then do it more out of spite against the alleged hoaxers. Think I'm joking?: https://www.scientificamerican.com/article/not-so-conservati...

Not having a sense of humour will hurt your cause more than anything. Given the choice between a secret fool who has fun, and a joyless thought-policing jerk who happens to be right on an issue, people will choose the fool every time; and frankly I can't blame them.

> Given the choice between a secret fool who has fun, and a joyless thought-policing jerk who happens to be right on an issue, people will choose the fool every time; and frankly I can't blame them.

It always amazes me that people who need so strongly to express their individualism in such ways are willing to tie their own puppet strings and offer to dance to another's will.

Re: The cost of parsing JSON

#308

Post by helpmepropose »

underwater wrote: post #265
helpmepropose wrote: post #259

I was hoping this blog post would be about the Chrome team speeding up JSON parsing. On a website I made[1] with a ~1MB JSON ajax payload, Chrome takes about 18 seconds to parse the JSON, while Safari parses it pretty much instantaneously. [1] https://helpmepropose.live EDIT: Does anyone know if there's something I could do differently to speed this up in Chrome?

Why not use binary data? A typed array should work (unsure of the exact APIs, though).

Hey underwater, I just wanted to follow up and say thanks. Without doing any other optimization, it seems that switching the ajax request from JSON to a big TypedArray changed Chrome's parsing time from 18 seconds to instantaneous: https://helpmepropose.live

Thanks again!

Post reply on HN