Re:I made JSON.parse() 2x faster
by radex on Saturday March 04, 2023 @03:30PM
(#35024223)
Thanks! There's a preliminary PR with a discussion here: https://github.com/facebook/hermes/pull/933 (and broader context here: https://github.com/facebook/hermes/issues/811 ). But we'll see if there's any interest on Hermes' side to merging it. They definitely want to improve the parser, but it's unclear to me if they want to take on the simdjson/simdutf dependencies.
Re:I made JSON.parse() 2x faster
by Waterluvian on Saturday March 04, 2023 @05:54PM
(#35025319)
This is delightful!
Maybe next you can make the object spread operator faster ;). I was recently bitten by it in a hot loop, thinking it was generally syntactic sugar. Turns out that if I know all the property names in an object, it’s far far faster to just assign them all manually.
Re:I made JSON.parse() 2x faster
by radex on Saturday March 04, 2023 @06:01PM
(#35025377)
That could be interesting! Curious: are you taking about a plain object spread, or are you talking about JSX spreads? The latter has more overhead. Also, which JS engine?
BTW. I recently measured the spread operator in a microbenchmark. Interestingly, while the native spread was faster on Hermes and JSC, it was slower on V8/Chrome, and it's faster there to use `Object.assign()`, i.e.:
Re:I made JSON.parse() 2x faster
by v0idzer0 on Saturday March 04, 2023 @07:08PM
(#35025797)
Doesn’t assigning properties behave differently? Spread creates a new object while assigning reuses the existing. Unless you mean creating a new object and then assigning the properties. I’d be surprised if that performed worse though. Also curious if the properties are primitives?
Re:I made JSON.parse() 2x faster
by bblackwood on Saturday March 04, 2023 @07:40PM
(#35025993)
Great blog post! As someone who isn't particularly familiar with javascript internals (or many language internals for that matter), this was really easy to follow and a lot of fun.
Re:I made JSON.parse() 2x faster
by i-use-nixos-btw on Saturday March 04, 2023 @08:01PM
(#35026100)
See, this is the difference between a productive engineer and a purist.
You are a productive engineer. You see a fast library that needs a different encoding, so your first thought is to add a transcoding step and make a 2x gain in a short timeframe.
I am a purist. I see a fast library that needs a different encoding, and my first thought is “ok, I’ll fork that library and make it work with UTF-16 natively”. 24 months later I’ll be found, bearded down to my kneecaps, staring at the bottom of a bottle of scotch, mumbling a mixture of curse words and “PowerPC”. But Id get a 2.05x speedup eventually, so…
Did they merge it?
Maybe next you can make the object spread operator faster ;). I was recently bitten by it in a hot loop, thinking it was generally syntactic sugar. Turns out that if I know all the property names in an object, it’s far far faster to just assign them all manually.
BTW. I recently measured the spread operator in a microbenchmark. Interestingly, while the native spread was faster on Hermes and JSC, it was slower on V8/Chrome, and it's faster there to use `Object.assign()`, i.e.:
['@babel/plugin-proposal-object-rest-spread', { loose: true, useBuiltIns: true }]
You are a productive engineer. You see a fast library that needs a different encoding, so your first thought is to add a transcoding step and make a 2x gain in a short timeframe.
I am a purist. I see a fast library that needs a different encoding, and my first thought is “ok, I’ll fork that library and make it work with UTF-16 natively”. 24 months later I’ll be found, bearded down to my kneecaps, staring at the bottom of a bottle of scotch, mumbling a mixture of curse words and “PowerPC”. But Id get a 2.05x speedup eventually, so…