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

211–220 of 308 posts

Re: The cost of parsing JSON

#211

Post by vorticalbox »

WorldMaker wrote: post #143
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.

Would like to know this aswell.

I know using spread

const clone = {...source};

Is faster than

object.assign({},source)

And seeing as in this case the source is already a js object it would probably be slow to string and the parse.

Re: The cost of parsing JSON

#212

Post by bryanrasmussen »

saagarjha wrote: post #202
bryanrasmussen wrote: post #180

Earlier quoted context omitted.

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.

I'm supposing template literals take care of that. actually there might be advantages.

Re: The cost of parsing JSON

#213

Post by geddy »

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(…)`

Guys - I think he was being hyperbolic. Ya know, like everyone does on the Internet. If he had said "if I had to look at JSON.parse(...) lines constantly, I'd jump off a building!" I doubt you all would be calling 911 over an attempted suicide.

Seriously, chill.

Re: The cost of parsing JSON

#214

Post by Gibbon1 »

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…

> And this was a very brilliant software engineer, but he was consistently making poor decisions like this.

That is something I've noticed. Brilliance doesn't go hand in hand with making prudent and wise decisions.

> I did my best to shield that software engineer from them

I've found rather painfully that you shouldn't shield guys like that when they go off on their own to make mistakes.

Other thing, you have a team of people that are familiar with how a codebase is put together and does things. And what sort of things go wrong. It's a bad idea to disrupt that 'just because' Goofus rewrites a module to use X fad. Great! Before there were five programmers who knew how that module worked and now there is one programmer who knows how that module works.

Re: The cost of parsing JSON

#216

Post by mamon »

pushpop wrote: post #186
TylerE wrote: post #157

Earlier quoted context omitted.

Some of us can’t just lost our health insurance on a whim.

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.

Re: The cost of parsing JSON

#217

Post by iamleppert »

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

Why do you care? It’s syntax and can be automated via build tools so you need not hurt your eyes with syntax that you consider to be unpleasant.

Which that’s the crux of the issue here, your opinion.

Re: The cost of parsing JSON

#218

Post by LgWoodenBadger »

hinkley wrote: post #158
alexis_fr wrote: post #129

Earlier quoted context omitted.

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.

That was a weird era in Java history. They changed the compiler in the subsequent major version to perform that transformation automatically, but by then people had had 2 years to stare at perf graphs looking for bottlenecks. It never was clear to me why they didn't do both of those in the same release. Backward compatibility wasn't the problem (they were already breaking that left and right).

Java devs saw that "abc" + "def" involved expensive String concatenation, so as a performance improvement they pro-actively, and effectively manually, changed to use explicit StringBuffer concatenations.

When the compiler switched to generate StringBuilder (unsynchronized) concatenations for "abc" + "def" nobody benefited, because they had already changed to use StringBuffer (synchronized).

Now they had to go an undo all of their hard, manual, optimization work.

I feel like the same would/might play out here.

Re: The cost of parsing JSON

#219

Post by Drdrdrq »

rhizome wrote: post #167
hinkley wrote: post #150

Earlier quoted context omitted.

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

Smells like a God Object pattern to me.

Apt term: https://en.m.wikipedia.org/wiki/God_object

Re: The cost of parsing JSON

#220

Post by munk-a »

Gibbon1 wrote: post #214
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…

> And this was a very brilliant software engineer, but he was consistently making poor decisions like this. That is something I've noticed. Brilliance doesn't go hand in hand with making prudent and wise decisions. > I did my best to shield that software engineer from them I've found rather painfully that you shouldn't shield guys like that when they go off on their own to make mistakes. Other thing, you have a team…

Assuming you are managing a dev (either through a lead role, seniority, or as a manager) you absolutely should shield team members from direct demands from up that chain - that's what most of your job is... Assuming the employee was acting within the rules you've laid out then the you should shield them and consider adjusting your rules to prevent a repeat - if, to contrast, your company has some CI tooling setup and automatic deploys and reviews and whatnot - but then someone edits a file on production... that might be a fireable offense.

Additionally to contrast - if you're a co-worker and not a manager then you may need to examine your relationship (are you a mentor and thus secretly leading them or just a colleague). If a pure colleague makes a mistake you shouldn't stick your neck out too much - except to force your common manager to properly defend them.

Everyone who is fired should be fired by their manager and not anyone else in the org - that's how a team is strong and healthy.

And

Managers, in a healthy company, own the mistakes their subordinates make.

Post reply on HN