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

131–140 of 308 posts

Re: The cost of parsing JSON

#131

Post by dfox »

pwg wrote: post #88
omginternets wrote: post #56

Earlier quoted context omitted.

Ah! Wow, that is surprising. Why was it so much faster?

In the beginning (8086/8088) because it was a shorter instruction encoding than the literal "move a zero into AX" instruction, so it created smaller code and saved a memory read (even if that read was a prefetch memory read). Later Intel actually special cased it in the instruction decoding path for the later CPU's (starting somewhere around the PII/PIII era, but I don't remember the exact timeframe) so that it also…

The reason why it is special cased is that on pipelined or OoO CPU, xor ax,ax would otherwise be significantly slower than straight mov as xor has dependency on its operand registers.

On a similar note on many RISC architectures NOP is actually something like ADD r0, r0, r0 and that too is usually special cased in the hazard stall and result forwarding logic (althought usually the special cased part is “ignore hazards that involve r0”)

Re: The cost of parsing JSON

#132

Post by 5trokerac3 »

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

First paragraph...

> This knowledge can be applied to improve start-up performance for web apps that ship large JSON-like configuration object literals

Third paragraph...

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

I'd fire people who don't RTFM

Re: The cost of parsing JSON

#133

Post by pier25 »

ijpoijpoihpiuoh wrote: post #73
pier25 wrote: post #24

Earlier quoted context omitted.

Is there a way to provide v8 with compiled code instead of unparsed JS?

I don't know about doing this directly with v8, but when used in the browser, the code will be cached after being compiled a certain number of times.

How many times?

Re: The cost of parsing JSON

#134

Post by SubuSS »

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…

define: hyperbole

noun exaggerated statements or claims not meant to be taken literally.

Re: The cost of parsing JSON

#135

Post by [deleted] »

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

[deleted]

Re: The cost of parsing JSON

#136

Post by vardump »

Battery life.

People seem to love to dismiss small improvements, even if they're practically effortless. Remember, faster performance equals lower battery consumption. Bad slow javascript causes browsers to waste energy.

Small things add up.

Re: The cost of parsing JSON

#137

Post by [deleted] »

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…

[deleted]

Re: The cost of parsing JSON

#138

Post by pier25 »

jackcodes wrote: post #64
pier25 wrote: post #24

Earlier quoted context omitted.

Is there a way to provide v8 with compiled code instead of unparsed JS?

While it isn’t exactly what you’re looking for, this is the closest thing I’m aware of for pure JS: https://prepack.io/ and outside of that o guess you’re looking at WASM, although I know this isn’t exactly what you were asking for. But if your goal is to compile a little closer to v8 then you’d have to set v8 as your compilation target, making that only really worthwhile on the server (since you’d be missing out on…

Thanks. I was thinking more about desktop apps (Elecron, CEF, etc).

Re: The cost of parsing JSON

#139

Post by bcoates »

seer wrote: post #130
flabbergast wrote: post #100

Earlier quoted context omitted.

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

Interesting how typescript plays into this - I mean back in the wild old days of plain old JS I would be totally fine with putting a JSON.parse here and there, especially on the hot path. But now with static types - this would totally wreck static type checking. And you would need to spend additional cycles to validate that the data is actually correct. Definitely a change request in the PR. This has to be probably a…

Can JS static typing not evaluate constant expressions to infer types?

Re: The cost of parsing JSON

#140

Post by samtheprogram »

alexis_fr wrote: post #129
flabbergast wrote: post #100

Earlier quoted context omitted.

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

That’s the compiler/minifier’s role anyway, to use the best construct when appropriate. See Java’s whole “abc”+”ced” vs StringBuilder performance issues. When programmers have to alter readability for performance, it doesn’t necessarily mean they shouldn’t do it, but it means the precompiler is not advanced enough.

I wish could upvote this more than once.

Readability is crucial in code. If you have to through and change the JSON that's being parse and it takes a nontrivial amount of time, that's a big setback. Sure, it's 1.7x faster (in v8) to parse JSON, but how long does it take to parse 10kb of an object literal in the first place? Given that these static, large objects are not common place in a codebase, is it worth the tradeoff?

The precomiler, such as Babel, could introduce a plugin for this sort of optimization. We only write ASM when it going to significantly change the performance characteristics, and typically when a particular code path is run many, many times throughout an application. If an object literal like this is getting parsed that frequently, there are better ways to optimize so that doesn't need to happen at all anyway.

I could see this being very useful in a variety of applications, such as server side rendering. However, its would be best to happen in an optimization phase as you're already bundling at that point.

Post reply on HN