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

101–110 of 308 posts

Re: The cost of parsing JSON

#101

Post by SamBam »

jacobr wrote: post #67
SamBam wrote: post #61

Earlier quoted context omitted.

It seems that you could define a subset of JS Objects that are exactly those you could define with JSON (no functions, no recursion), and the browser could always read these more efficiently. With modern tooling, these could probably even be automatically be discovered at compile time, and all your `const a = {b: "c"}` objects could be changed into `const a = SimpleObject({b: "c"})`. Without that, you could probably…

There is no way of knowing someone won’t do a.foo = window.alert later though, unless it’s a frozen object

The speed-up is at object instantiation.`a.foo = window.alert` could only be done post instantiation.

Re: The cost of parsing JSON

#102

Post by nostrademons »

michaelmcmillan wrote: post #13

So I guess we should "transpile" static objects into strings that we call with JSON.parse? Not sure if I should end this comment with a /s or not.

WebPack, properly configured, will let you import plain old .json files through the normal es6 import mechanism. It doesn't use this technique though: the JSON file is treated as normal JS source (preprocessed to remove unnecessary quotes etc.) and wrapped with an export.

Re: The cost of parsing JSON

#103

Post by untog »

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 be (or current implications in non V8 engines?) but this trend of prioritising developer experience over everything feels like a very bad one to me. It's the same reason given to justify making every web site a React app with no thought toward the extra JS payload you're sending when it's not needed.

Re: The cost of parsing JSON

#105

Post by murderfs »

tomtomtom777 wrote: post #95
murderfs wrote: post #74

Earlier quoted context omitted.

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.

> It would be ridiculous to have a short encoding for `mov rN, #imm` where the immediate has to be in the range 0-7. Such instruction didn't exist but I wouldn't call it ridiculous . It would actually be quite useful as setting a register to 3 is far more common than setting a register to 7911.

If you're going to do something like that, you might as well steal from the register numbering bits instead.

(many architectures have done this: Intel has lots of short-form encodings for "op {al, ax, eax, rax} #imm", and ARM has Thumb, which basically chops the register count in half for all instructions to shorten their encoding)

Re: The cost of parsing JSON

#106

Post by drtz »

Couldn't this same performance boost be achieved by adding an optional "strict mode"-like flag for object literals to v8? Adding JSON.parse(…) everywhere you need an object literal seems exceptionally kludgy, even for JS.

Re: The cost of parsing JSON

#107

Post by partialrecall »

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…

Users like code with fewer bugs and rapid response time for new feature requests, right? If you start firing people for taking the time to write readable and maintainable code, you'll be doing a greater disservice to the users than those developers were.

Re: The cost of parsing JSON

#108

Post by NilsIRL »

contravariant wrote: post #89
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.

Either way it's really more data than object at that point so it's appropriate to store it as JSON. Normally I'd place such data in a different file, but I can imagine that that might not be best for webpages.

> fata

you created a noun to describe "fat data" from a typo.

Re: The cost of parsing JSON

#109

Post by eyelidlessness »

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 totally agree that inlining `JSON.parse` of string literals in source is a bad idea and I would reject it in a code review except under the most extreme circumstances (and even then try to identify a better solution).

On the other hand, knowing the performance characteristics, this is something that compilers could do as an optimization. Who knows if that's worth the effort, but this kind of research is part of determining that.

Re: The cost of parsing JSON

#110

Post by sbr464 »

Klathmon wrote: post #99
sbr464 wrote: post #97

Earlier quoted context omitted.

You can also pretty easily use a web worker now, they work well. Here's [1] an example with React hooks. Example fibonacci worker code that doesn't block the UI, even at larger calculations const fib = n => (n { console.log('fibonacci worker onmessage', msg) postMessage({ num: msg.data, result: fib(msg.data) }) } [1] https://github.com/bharathnayak03/react-webworker-hook

Web workers won't work in this case because they need to serialize all data going into and out of them (with the exception of TypedArrays). So passing a string to a worker and having it JSON.parse it works great. But when you go to pass that object back to the main thread, it implicitly does a JSON.stringify and a JSON.parse back on the main thread (technically it's called a "Structured Copy", but it's mostly the sam…

Good to know, thanks for clarifying.
Post reply on HN