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

171–180 of 308 posts

Re: The cost of parsing JSON

#171

Post by Ensorceled »

hinkley wrote: post #154
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.

I usually find the opposite. Firing someone for cause is interminable or outright impossible, unless they're breaking the law or embarrassing you in front of customers.

I have only once fired for cause. Every other time, I’ve gone through the process, the PIP, and then terminated them according to their contract, usually with “more generous the legally or contractually required” severance. Let’s me sleep at night and has the nice side effect of keeping the peace with the remaining team.

Re: The cost of parsing JSON

#172

Post by tracker1 »

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

For the main two apps I work on, there's some configurations that are different between different client deployments, this includes i18n strings, configuration settings/options, theme options and a couple of images (base64 encoded) for theming. Switching to JSON.parse was a pretty significant impact, from about over 200ms to under 100ms for my specific use case (IIRC). Memory usage was also reduced.

I don't remember the specific numbers... it was an easy change in the server handler for the base.js file that injects a __BASE__ variable.

    var clientConfig = JSON.Stringify(base.Env.Settings.ToClient(null)).Replace("\"", "\\\"");
    // NOTE: JSON.parse is faster than direct JS object injection.
    ClientBase = $"{clientTest}\nwindow.__BASE__ = JSON.parse(\"{clientConfig}\")";
    ...
    return Content($"{ClientBase}\n__BASE__.acceptLanguage=\"{lang}\";", "application/javascript");
The top part is actually a static variable that gets reused for each request, the bottom is the response with the request language being set for localization in the browser app.

Re: The cost of parsing JSON

#173

Post by eterm »

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…

To be honest I think it's a big mistake on the part of typescript to not have a JSON.parse.

Re: The cost of parsing JSON

#174

Post by pas »

CountHackulus wrote: post #168

So I guess AOT compilation is coming? That seems to be the next logical step. Cache compiled versions of your code in a format that can be loaded directly into memory. Java does it if set up to do so and it definitely gets better startup performance. Plus you get a pre-warmed compile cache.

Isn't this what WASM was supposed to be?

Re: The cost of parsing JSON

#175

Post by dkersten »

filoleg wrote: post #152
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.

Eh, depends on the reasons for firing people easily. Firing easily for honest errors is moronic, fully agreed, especially if the person is learning from them. My code changes caused more than one sev0 before, but never was I personally blamed for them, as it was always some bigger underlying system issue that wouldn't have allowed me to make those mistakes, if the systems were more robust (and I was a little bit more…

I’m not against firing people if they are a bad fit, are incompetent or are toxic to the work environment. I’m against firing people for small things, not giving a chance to improve, firing on a whim or simply discarding people. Treat people like humans, but that doesn’t mean you can’t fire people who are a negative force on your business.

Re: The cost of parsing JSON

#176

Post by TeMPOraL »

ppeetteerr wrote: post #162
SirensOfTitan wrote: post #112

Earlier quoted context omitted.

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

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.

Re: The cost of parsing JSON

#177

Post by tracker1 »

chuckgreenman wrote: post #83
edf13 wrote: post #63

Earlier quoted context omitted.

No there’re not

Most development time is going to be spent on reading code that's already written, so yes, they do matter. With the speeds mentioned it's not going to be appreciable until you hit a massive scale, which, let's face it, most of us aren't working with.

Well, we're talking about injected variables...

    const injectedValue = JSON.parse("$SERVER_JSON_VALUE.replace("\"","\\\"")");
    // vs
    const injectedValue = $SERVER_JSON_VALUE;
generally for a single value in the codebase is emphatically NOT a huge issue... and if it saves 80-120ms or so on the load, that's a significant impact. Not to mention the lower memory overhead while doing so.

Re: The cost of parsing JSON

#178

Post by tracker1 »

Klathmon wrote: post #62
Tade0 wrote: post #48

I think this fragment catches the spirit of this piece: 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. Although it may still not be worth it. At work I have this hand-rolled utility for mocking the backend using a .har file(which is a JSON). I use it to reproduce bugs found by the testers, who…

I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1]…

Would probably break that up similar to how you did in that case as well. Though may use multiple server request (chunks) and/or use a websocket for the data feed.

What was the memory overhead for the application?

Re: The cost of parsing JSON

#179

Post by tracker1 »

Sephr wrote: post #111
IggleSniggle wrote: post #12

Commenting the security issue from the end of explainer for visibility. I’m having flashbacks to the Java serialize vulnerabilities from a couple years ago. ECMAScript and JSON do not have the same set of escape characters: ``` Note: It’s crucially important to post-process user-controlled input to escape any special character sequences, depending on the context. In this particular case, we’re injecting into a tag, s…

Why would you ever be escaping HTML in client-side JS? You should be using appropriate DOM APIs (which don't include innerHTML) to manipulate the document.

If the JSON itself contains strings with markup included, and you're injecting directly into a script tag in the HTML document.

Though, if you're dealing with a typed object server-side and/or loading into a .js file request, it's less of an issue, if you aren't supporting html markup in the object to begin with. In my own use case, both are true.

Re: The cost of parsing JSON

#180

Post by bryanrasmussen »

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…

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 for developer speed = productivity purposes.
Post reply on HN