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

201–210 of 308 posts

Re: The cost of parsing JSON

#201

Post by Klathmon »

lossolo wrote: post #197
nostrebored wrote: post #182

Earlier quoted context omitted.

Thank you for the excellent explanation! I think of js entirely from a node.js perspective where I conceptualize it as an async task. Is this also wrong?

> Is this also wrong? Yes, node.js javascript runtime is based on V8, the same that runs in Chrome. Javascript is single threaded so anything that is not I/O bound will block the main thread. If you don't want to block the thread becasue you have long running calculation/parsing task, then you can use worker threads[1]. This will run your task in separate thread and not block the main one. [1] https://nodejs.org/dist…

and not to beat a dead horse, but worker threads again wouldn't work in this exact situation even in Nodejs. They suffer from the same problems that web-workers do, meaning they use a structured copy algorithm to send data between workers (with the exception of TypedArrays), and therefore would hang the "main thread" just as long as if you did the `JSON.parse` directly in it.

It's a really annoying problem, and I'm actually really happy to see that many others have the exact same thoughts I had at the time, and that I wasn't just missing something obvious!

Re: The cost of parsing JSON

#202

Post by saagarjha »

bryanrasmussen wrote: post #180
19ylram49 wrote: post #163

Earlier quoted context omitted.

To be honest, I understand the bit of backlash that I’ve received here and I think it’s well-deserved since I should’ve worded my statement better. Thank you for your comments. You all are correct re firing someone over mistakes and seemingly trivial matters. I was mostly referring to software engineers who make impactful decisions without good reason and/or without properly assessing the trade-offs. I think it’s fai…

I agree with everything you said, except that I'm not sure that JSON.parse all over the place is going to add any significant unreadability. I think most likely it would always look the same and be just as readable as object literals once the initial getting used to it period would be over with. Hell, I think it's a lot more readable than the use of !! which I consider an abomination, but everyone keeps doing that fo…

It might be more difficult to format a string literal.

Re: The cost of parsing JSON

#203

Post by liara_k »

beatgammit wrote: post #189
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…

You're extrapolating quite a bit from a simple comment, which tells me that you'd probably be a poor manager as well. Then again, I'm extrapolating quite a bit as well. Seeing something like JSON.parse throughout the code is definitely a code smell and could decrease the maintainability of the codebase, and that's a very tangible problem. Obviously you shouldn't fire someone over something like this if it's the first…

"We apologize for the fault in the subtitles^Hjavascript. Those responsible have been sacked."

"Those responsible for sacking the people who have just been sacked have been sacked"

"The directors of the firm hired to continue the credits after the other people had been sacked, wish it to be known that they have just been sacked."

Re: The cost of parsing JSON

#204

Post by Klathmon »

sbr464 wrote: post #110
Klathmon wrote: post #99

Earlier quoted context omitted.

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.

And thanks to you for helping show me that I wasn't the only one to try that!

This whole thread has been really nice to read, because I beat my head against a wall for a long time before I finally found a solution, and I'm glad to read that I wasn't the only one to think this was a lot more deceptively hard than I thought at first thought (or second, or third...)

Re: The cost of parsing JSON

#205

Post by zaroth »

Klathmon wrote: post #120
penagwin wrote: post #116

Earlier quoted context omitted.

I'm asking purely out of curiosity - what was the content of such a large JSON object?

It was a carton scanning app, so basically a massive array of objects (carton data) which were needed so the app could function and route cartons and validate deliveries entirely offline. Due to some unfortunate limitations from our clients and some edge cases, we couldn't filter down the data on the server ahead of time. So we ended up having to keep that massive amount of data on the device, and at the end of the d…

I kept reading that as cartoons and I was just so confused for a second...

Re: The cost of parsing JSON

#206

Post by adimitrov »

19ylram49 wrote: post #163
dkersten wrote: post #121

Earlier quoted context omitted.

You probably wouldn't want to work for somebody who fired people so easily anyway. This is one reason why I find it stupid when people defend companies or are super loyal to their employers: companies don't care about you and especially companies that fire on a whim without concern that they're fucking with somebodies life. Best to work somewhere that treats you like a human instead of as a cog.

To be honest, I understand the bit of backlash that I’ve received here and I think it’s well-deserved since I should’ve worded my statement better. Thank you for your comments. You all are correct re firing someone over mistakes and seemingly trivial matters. I was mostly referring to software engineers who make impactful decisions without good reason and/or without properly assessing the trade-offs. I think it’s fai…

> Part of me still thinks that he just wanted to learn/use the JNI and that project seemed like the perfect target. Lol.

As a dev who sometimes goes off chasing wind mills, that's 99% of the reason why I do it. I find something nice to tinker with, and when my brain goes "ooh, shiny" I stop giving a shit about anyone's bottom line.

To be fair, it usually turns out for the better for the project and its code base! But sometimes it doesn't, and I figure that's just the cost of doing business. Companies should be willing to take these kinds of informed risks in order to improve their employees' ability, and therefore the quality of their product. However, a lot of management only sees the short term gain, because long term gain isn't incentivized for them. They just wanna do well and get a promotion.

Well, guess what, it's the same for me. Except for me to do well, I have to be learning new things constantly. So tough poop, management, I'll be chasing my white whale every once in a while. Deal with it.

Re: The cost of parsing JSON

#207

Post by 19ylram49 »

adimitrov wrote: post #206
19ylram49 wrote: post #163

Earlier quoted context omitted.

To be honest, I understand the bit of backlash that I’ve received here and I think it’s well-deserved since I should’ve worded my statement better. Thank you for your comments. You all are correct re firing someone over mistakes and seemingly trivial matters. I was mostly referring to software engineers who make impactful decisions without good reason and/or without properly assessing the trade-offs. I think it’s fai…

> Part of me still thinks that he just wanted to learn/use the JNI and that project seemed like the perfect target. Lol. As a dev who sometimes goes off chasing wind mills, that's 99% of the reason why I do it. I find something nice to tinker with, and when my brain goes "ooh, shiny" I stop giving a shit about anyone's bottom line. To be fair, it usually turns out for the better for the project and its code base! But…

Lol. That’s the spirit!

Re: The cost of parsing JSON

#208

Post by zeven7 »

tracker1 wrote: post #191
zeven7 wrote: post #76

Earlier quoted context omitted.

That's also true of an object parsed with JSON.parse

JSON.parse won't parse a function call/literal. Direct injection would.

You're right about that, but I don't think you're following the argument. The argument was that there could be a `SimpleObject` that's limited and parses quicker. A `SimpleObject` wouldn't parse a function call, just like JSON.parse.

As OP said, "subset of JS Objects". This subset of JS objects wouldn't support function calls.

Re: The cost of parsing JSON

#209

Post by ijpoijpoihpiuoh »

pier25 wrote: post #133
ijpoijpoihpiuoh wrote: post #73

Earlier quoted context omitted.

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?

According to the fine article, twice in three days.

Re: The cost of parsing JSON

#210

Post by Drdrdrq »

TeMPOraL wrote: post #176
ppeetteerr wrote: post #162

Earlier quoted context omitted.

I would also micromanage this way. Developers leave, code remains. If your code base is full of `JSON.parse(...)` in a few years because of some developer who though "how clever to do this instead of object literals" it's not the author who has to live with their decision, it's the next code maintainer. I see too many programmers being too clever and then leaving their clever code to become someone else's issue. My a…

Tough life that maintainer is going to have, seeing `JSON.parse(...)` being wrapped around object literals in code. This truly is going to cost them many man hours and lots of hair pulled out in stress. Seriously though, there's clever code and then there's just nitpicking. Micro-optimizations with JSON.parse() look ugly and nullify some editor conveniences, but they're IMO very far from being a fireable offense.

They are not a fireable offense in my book either, but they sure as hell wouldn't pass my code review. I've had to deal with too much crap like this in the past. Self-proclaimed senior devs that micro-optimize everything and leave a mess, then leave. Love them.

One should always optimize for easy maintenance. Performance is always a secondary goal, because it doesn't matter how fast (you think) your code is if you can't understand it.

Post reply on HN