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

251–260 of 308 posts

Re: The cost of parsing JSON

#251

Post by AgentOrange1234 »

est31 wrote: post #235
EB66 wrote: post #231

Earlier quoted context omitted.

We're talking about JavaScript in the browser though... what other message format is more readily and performantly processed in-browser using JavaScript than JSON?

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 don’t think this is a one-or-the-other situation.

“Bloat” is a problem on, say, news sites with horrible ads and it’d be great if they kept it lean. Obviously they don’t need webassembly and binary formats.

But... there are also incredibly powerful tools (google maps and docs, quake in the browser, streaming services, etc) that push the boundaries, which these kinds of tech will enhance, or make possible in the first place.

Re: The cost of parsing JSON

#252

Post by AgentOrange1234 »

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

TFA says this is could make sense for objects over 10kb. They clearly aren’t advocating doing it everywhere in a code base.

Re: The cost of parsing JSON

#253

Post by core-questions »

tabtab wrote: post #240
gnarbarian wrote: post #230

Earlier quoted context omitted.

Parsing 1GB of flat JSON data is equal to 1.61 metric cow farts.

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

Literally parsing carbon-shittons of JSON right now out of spite. It's worth the spot instance cost! Especially since the power usage + carbon created is on the other side of the world from me! Mwahahah!

relaxes in pure pristine air-shed

Re: The cost of parsing JSON

#254

Post by Roboprog »

drinchev wrote: post #190

Well I guess this means that if you have a 1k+ lines of static JSON, it would be better if you consider converting it to a string and use JSON.parse instead. I'm not sure I can find a use case of such a big object declaration. Usually what you do is to get it from somewhere ( file, db - with nodejs, xhr ) where it's been parsed with JSON.parse anyway.

I guess somebody needed to do that, but I am totally with you that this sounds like a follow up request or read for metadata to me.

Re: The cost of parsing JSON

#255

Post by Roboprog »

eloff wrote: post #26
cryptica wrote: post #18

This is a terrible idea. 2x best-case performance is nothing. Especially not worth the extra hassle and complexity that it adds to the code. The sad thing about these kinds of articles is that there are people out there who will read this and actually start implementing it in their code.

JSON.parse is complexity? Just separating your data from your code alone is worth it for the architectural benefits, this would be a net improvement to code quality. Performance matters, if you have a lot of data like this that can also be a big win.

Reading the data structure within the string is rather a nuisance, I think.

It’s worth noting the caveat that there is a minimum size where this trick has a noticeable effect, though.

I understand the original comment’s fear of abuse. Nice to know it’s there for huge data structures though. Huge: we’re talking about a browser, not a database server.

Re: The cost of parsing JSON

#256

Post by amalcon »

mamon wrote: post #216
pushpop wrote: post #186

Earlier quoted context omitted.

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.

If you're not paying for it with your money, then you have to pay with your time: public healthcare systems, like those in Europe are known for the long wait times for patients requiring surgery, or other costly procedures. Also, traveling to the US for treatment is still a thing, because new, advanced treatments are developed and first implemented in the US, so all that money spent give you something in return.

In the US, you generally need to pay with both your money and your time. I've waited three months for an appointment with a specialist, had them only tell me to go to another specialist, and paid for the privilege.

Re: The cost of parsing JSON

#257

Post by kllrnohj »

manfredo wrote: post #232
kllrnohj wrote: post #122

Earlier quoted context omitted.

> benchmark against protobuf decoding Protobuf isn't built into the browser, so it can't bypass the JS parse & execute time. Instead you'd be parsing protobuf's JS, executing it, parsing proto, and producing objects. It'd be worth doing, sure, but it'd almost certainly be the slowest option by far since it's doing way more stuff in JS than either of the other two options and the JS syntax parse is the slow part.

These benchmarks indicate better protobuf performance [1]. Compute time these days is often dominated by memory transfer rates. The "slowness" of javascript seems to be offset by there being less data to begin with. Collapsing a 100KB resource down to, 50 or 25KB is usually worth it even if you have to do more operations in javascript. Not to mention end to end load time (which is probably what people are usually try…

> 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 optimize for) can be lower by reducing how much data needs to travel over the wire or radio.

Wire transfer size would need to be looked at differently. The JS code & JSON string are both also going to be compressed unless you're not using a compressed Content-Type for some reason.

Re: The cost of parsing JSON

#258

Post by krferriter »

dkersten wrote: post #170
tyri_kai_psomi wrote: post #155

Earlier quoted context omitted.

counterpoint: you are just as free to take the same liberty with your employer. You can drop them like a bad date, and take a job somewhere else. additional counterpoint: part of your job as being a grown up responsible adult is your ability to manage and endure risk and loss, especially the risk of your job disappearing overnight. Outside of circumstances of extreme poverty, or extreme disability, in which our gover…

Its an uneven power dynamic though. The employers typically hold many more cards than the employees.

"typically"? I think you mean "always". This notion of it being an equal relationship in both directions is ridiculous.

Re: The cost of parsing JSON

#259

Post by helpmepropose »

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?

Re: The cost of parsing JSON

#260

Post by stu_k »

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…

You might be interested in a tool I wrote to serve .har files called server-replay: https://github.com/Stuk/server-replay

It also allows you to overlay local files, so you can change code while reusing server responses.

Post reply on HN