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

141–150 of 308 posts

Re: The cost of parsing JSON

#141

Post by epx »

murderfs wrote: post #74
jedimastert wrote: post #66

Earlier quoted context omitted.

There's a bunch of overhead associated with reading a constant from the program and moving that to the register. Math operations, on the other hand, are very simple to do because it's baked right into the CPU, only requiring one instruction and a few cycles

No, the reason is that `xor ax, ax` has a shorter encoding, because it only takes 3 bits to encode a register on 32-bit x86, and far more bits are required for a useful immediate move. It would be ridiculous to have a short encoding for `mov rN, #imm` where the immediate has to be in the range 0-7.

Trivia: MIPS and RISC-V have the r0 register equal to zero to optimize this case in a more elegant way.

Re: The cost of parsing JSON

#142

Post by WorldMaker »

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…

Typescript gives you type checking if you import from a JSON file. (Node handles JSON imports and webpack will happily build that for you into a JSON.parse in a bundle.)

Re: The cost of parsing JSON

#143

Post by WorldMaker »

epx wrote: post #33

This is the XOR AX,AX of the 21th century

I've wondered about that with JSON.parse(JSON.stringify(obj)) being the fastest way to deep clone a plain JS object in any JS engine. It always looks dumb when it shows up, but it works well enough and I've seen it described as a best practice by some types of data manipulation libraries.

Re: The cost of parsing JSON

#144

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

#145

Post by asdkhadsj »

SirensOfTitan wrote: post #112
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…

Love the quote. Though, I have some people working with me who I would still struggle with that quote. There is an assumption in it that the employee grows from the experience.. yet, I face people who seemingly make an effort not to grow.

Re: The cost of parsing JSON

#146

Post by adossi »

nicoburns wrote: post #127

I wish there was an option for off the main thread ("async") parsing of JSON. It's easy to cause UI lag by parsing (or serializing) large objects, and this seems very unnecessary.

I see this sentiment echoed a few times in this discussion thread. I use JSON daily, parsing and serializing everywhere, and yet I've never been in a scenario where I needed to parse a very large JSON object on the client side. The biggest JSON objects I work with are in the neighborhood of ~80 MB, but the client's browser never sees those behemoths. At most I return a few KB to the client's browser via an API response where it is then parsed and consumed.

Is this notably a problem where the back-end is written in JavaScript?

Re: The cost of parsing JSON

#147

Post by [deleted] »

SirensOfTitan wrote: post #112
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…

[deleted]

Re: The cost of parsing JSON

#149

Post by aflag »

dfox wrote: post #131
pwg wrote: post #88

Earlier quoted context omitted.

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

Adding the same register to itself and then assigning the value to itself is not really a nop. Why is that instruction forbidden and converted to a nop instead?

Re: The cost of parsing JSON

#150

Post by hinkley »

Klathmon wrote: post #68
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).

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.

Like a lot of people who have given interviews, I have my own set of very odd stories.

I interviewed a developer and asked him to explain how the system he was currently working on worked on the whiteboard. As he talked he drew two boxes. He drew a line between those boxes. Then as he talked he kept drawing over the line between the boxes. (Now, he was jr to mid-career so I didn't expect a magnum Opus but we value people who can explain themselves because at least if they're wrong we find out before the mess gets too big. But I digress.)

Your analysis reminded me of that interaction. What kind of information architecture do you have if you're building objects that big?

I mean, as others have said, if this is the main payload being transferred from client to server, it's probably going to arrive as JSON and you're going to turn it into Objects.

If it's not that data (they're talking about cold loads) how many other categories do you have that can approach 10k?

Configuration? We have libraries for that and they often read a JSON file.

Lookup tables for fixed relationships of data in the system? Maybe, but that complicates your testing situation.

How many of those categories get loaded more than once per session? Are these really such large startup bottlenecks that we tackle this instead of other problems? GP implied incompetence but I get more of a whiff of desperation here.

Post reply on HN