5 ms·

I hate these microperformance hacks. There’s no way you’re going to have a bottleneck here and you’re making the quality of your code dramatically worse.

moltar 7y ago
I don’t think this is meant to be hand written though. But a bundle/compiler can do this optimization for you.
- jammygit 7y ago
  This did not occur to me but is obvious now that you have said it. Interesting! I wonder how many such tweaks it would take it to be worthwhile for companies to add it as a build step
  - microwavecamera 7y ago
    I understand what you and OP are getting at and I'm saying it's wrong but it misses the broader point that others posters were positing. The exact same point I came to make but found myself in good company. Why?!? And it's not specific to JS or a direct criticism of JS, this issue it becoming endemic. It's happening everywhere now. We shouldn't have to depend on language specific hacks to make things "work" in that language. JS has gotten so out of hand now we have/need new metalanguages like TypeScript, CoffeeScript, Bable, (insert buzzwordy JS lang here) that transpiles into JS because it's become so unwieldy. All this just to be able to make a simple web app. The fact that V8 can parse JSON faster than processing a native JS literal is a compiler problem. Why is it suddenly my problem? It's one thing if it's a bug that we have to temporarily work around (these things happen) but now it's becoming the norm. How are people new to the industry supposed to learn something like JS if the only way to be proficient at it is through an endless, ever changing array of hacks? Especially when it's something as counterintuitive as parsing a string is somehow faster than the actual equivalent code. The "move fast and break things" mentality that has permeated tech as of late has done just that, got us nowhere fast and broke everything along the way.
    - manigandham 7y ago
      Javascript is messy but it's everywhere and has gotten significantly better with recent versions. Typescript is just a different flavor offering strong typing and other features, just like Scala or Kotlin can also replace Java if you want. This particular hack is absolutely nothing you have to worry about, just like esoteric performance tweaks available in any language stack. Write the JS you need and use it. Then profile and optimize as necessary.
    - moltar 7y ago
      You can apply all of the same reasoning to assembly. People did write that by hand at some point. Then they abstracted that away into higher level languages. I’m sure there’s a ton of hackery going on there as well. It just seems like a human nature to paper over. It’s an evolution.
yomly 7y ago
I met someone recently who had to do pretty high performance JS to ship webapps targeting feature phones - presumably every bit of performance helps there and as someone else mentioned, the compiler can probably do this bit for you
- baron816 7y ago
  Sure, but 99.99% of devs don’t need to know this and probably shouldn’t know this lest they decide one day “this will be faster so I’ll just do it this way” not thinking of how awful and confusing it will be for everyone else.
  - vram22 7y ago
    Plus, in some future implementation, it could happen that the current faster way becomes slower, due to changes in the JS interpreter / JITter etc. At least, think it could. Not a language lawyer or implementer.
    - coding123 7y ago
      Yeah I'm getting a frustrated feeling like the entire ""+"" debate in Java all over again.
  - maxxxxx 7y ago
    And others will copy this pattern without knowing why. so quickly you have these weird patterns all over your code.
fenomas 7y ago
The article suggests that for large static things like config data. It's not suggesting anyone write their object declarations that way.
gameswithgo 7y ago
yep, be nice if the normal way of doing things was the fast way, in the language we decided to make ubiquitous wouldn’t it.
deleted 7y ago
[deleted]
outside1234 7y ago
I hate that this micro performance hack actually is better - why don’t they just fix this in the JIT so that the literal is just as fast as the JSON parse? Why do we have to think about this?
- badamp 7y ago
  It isn’t a jit issue it is a parsing issue. Also micro performance becomes macro at scale. This is not something that you worry or think about with a handful of literals. It would be good for an inner loop or code generator.
  - whatshisface 7y ago
    You wouldn't write this in an inner loop, you would do it once in the entire program. It's a literal object that doesn't change.
- baddox 7y ago
  The runtime can't know whether it's parsing a plain old JSON-compatible object literal until it, well, parses it.
  - pbhjpbhj 7y ago
    IANAProgrammer but couldn't it do like try..catch and assume it's JSON compatible and fall back to the [much] slower method if the parse fails? Does that cost too much time/resources?
    - daleharvey 7y ago
      That would make all JavaScript that has non JSON object literals (most JS code) slower
      - pbhjpbhj 7y ago
        How much slower? We already established it's far slower parsing js; in most cases JSON parsing would fail - IIRC - on the first character ^[^{] ... so would it be worth being slower by the time it takes to check the first character, and then only JavaScript that started with { would be slower. Which I guess is virtually none. I suppose those sorts of questions are part of what makes language design interesting.
baddox 7y ago
It's actually pretty common for single-page apps to have a large amount of configuration data (e.g. all the client-side routes) and potentially a large of amount of application data sent from the server-side renderer. And code compilation can be a significant part of the cold-boot time for large single-page apps. I haven't verified, but it's very conceivable that this would significantly speed up time-to-interactivity for a very large single-page app.
- DrOctagon 7y ago
  Henrik Joreteg has a recent blog post on this: https://joreteg.com/blog/improving-redux-state-transfer-performance https://joreteg.com/blog/improving-redux-state-transfer-perf... (note caveats/questions at the end of the article)
sequoia 7y ago
hear hear!
madeofpalk 7y ago
> There’s no way you’re going to have a bottleneck here and you’re making the quality of your code dramatically worse A tweet was going around that this change lead to a 30% increase in time-to-interactive. If you're dumping Redux state from the server onto the page, you could benefit from it, and it's really only one place so its not actually making your overall code "dramatically worse".
moojd 7y ago
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. Might be worth investigating if you have a ton of JSON.

moltar 7y ago

I don’t think this is meant to be hand written though. But a bundle/compiler can do this optimization for you.

jammygit 7y ago
This did not occur to me but is obvious now that you have said it. Interesting! I wonder how many such tweaks it would take it to be worthwhile for companies to add it as a build step
- microwavecamera 7y ago
  I understand what you and OP are getting at and I'm saying it's wrong but it misses the broader point that others posters were positing. The exact same point I came to make but found myself in good company. Why?!? And it's not specific to JS or a direct criticism of JS, this issue it becoming endemic. It's happening everywhere now. We shouldn't have to depend on language specific hacks to make things "work" in that language. JS has gotten so out of hand now we have/need new metalanguages like TypeScript, CoffeeScript, Bable, (insert buzzwordy JS lang here) that transpiles into JS because it's become so unwieldy. All this just to be able to make a simple web app. The fact that V8 can parse JSON faster than processing a native JS literal is a compiler problem. Why is it suddenly my problem? It's one thing if it's a bug that we have to temporarily work around (these things happen) but now it's becoming the norm. How are people new to the industry supposed to learn something like JS if the only way to be proficient at it is through an endless, ever changing array of hacks? Especially when it's something as counterintuitive as parsing a string is somehow faster than the actual equivalent code. The "move fast and break things" mentality that has permeated tech as of late has done just that, got us nowhere fast and broke everything along the way.
  - manigandham 7y ago
    Javascript is messy but it's everywhere and has gotten significantly better with recent versions. Typescript is just a different flavor offering strong typing and other features, just like Scala or Kotlin can also replace Java if you want. This particular hack is absolutely nothing you have to worry about, just like esoteric performance tweaks available in any language stack. Write the JS you need and use it. Then profile and optimize as necessary.
  - moltar 7y ago
    You can apply all of the same reasoning to assembly. People did write that by hand at some point. Then they abstracted that away into higher level languages. I’m sure there’s a ton of hackery going on there as well. It just seems like a human nature to paper over. It’s an evolution.

yomly 7y ago

I met someone recently who had to do pretty high performance JS to ship webapps targeting feature phones - presumably every bit of performance helps there and as someone else mentioned, the compiler can probably do this bit for you

baron816 7y ago
Sure, but 99.99% of devs don’t need to know this and probably shouldn’t know this lest they decide one day “this will be faster so I’ll just do it this way” not thinking of how awful and confusing it will be for everyone else.
- vram22 7y ago
  Plus, in some future implementation, it could happen that the current faster way becomes slower, due to changes in the JS interpreter / JITter etc. At least, think it could. Not a language lawyer or implementer.
  - coding123 7y ago
    Yeah I'm getting a frustrated feeling like the entire ""+"" debate in Java all over again.
- maxxxxx 7y ago
  And others will copy this pattern without knowing why. so quickly you have these weird patterns all over your code.

fenomas 7y ago

The article suggests that for large static things like config data. It's not suggesting anyone write their object declarations that way.

gameswithgo 7y ago

yep, be nice if the normal way of doing things was the fast way, in the language we decided to make ubiquitous wouldn’t it.

deleted 7y ago

[deleted]

outside1234 7y ago

I hate that this micro performance hack actually is better - why don’t they just fix this in the JIT so that the literal is just as fast as the JSON parse? Why do we have to think about this?

badamp 7y ago
It isn’t a jit issue it is a parsing issue. Also micro performance becomes macro at scale. This is not something that you worry or think about with a handful of literals. It would be good for an inner loop or code generator.
- whatshisface 7y ago
  You wouldn't write this in an inner loop, you would do it once in the entire program. It's a literal object that doesn't change.
baddox 7y ago
The runtime can't know whether it's parsing a plain old JSON-compatible object literal until it, well, parses it.
- pbhjpbhj 7y ago
  IANAProgrammer but couldn't it do like try..catch and assume it's JSON compatible and fall back to the [much] slower method if the parse fails? Does that cost too much time/resources?
  - daleharvey 7y ago
    That would make all JavaScript that has non JSON object literals (most JS code) slower
    - pbhjpbhj 7y ago
      How much slower? We already established it's far slower parsing js; in most cases JSON parsing would fail - IIRC - on the first character ^[^{] ... so would it be worth being slower by the time it takes to check the first character, and then only JavaScript that started with { would be slower. Which I guess is virtually none. I suppose those sorts of questions are part of what makes language design interesting.

baddox 7y ago

It's actually pretty common for single-page apps to have a large amount of configuration data (e.g. all the client-side routes) and potentially a large of amount of application data sent from the server-side renderer. And code compilation can be a significant part of the cold-boot time for large single-page apps. I haven't verified, but it's very conceivable that this would significantly speed up time-to-interactivity for a very large single-page app.

DrOctagon 7y ago
Henrik Joreteg has a recent blog post on this: https://joreteg.com/blog/improving-redux-state-transfer-performance https://joreteg.com/blog/improving-redux-state-transfer-perf... (note caveats/questions at the end of the article)

sequoia 7y ago

hear hear!

madeofpalk 7y ago

> There’s no way you’re going to have a bottleneck here and you’re making the quality of your code dramatically worse A tweet was going around that this change lead to a 30% increase in time-to-interactive. If you're dumping Redux state from the server onto the page, you could benefit from it, and it's really only one place so its not actually making your overall code "dramatically worse".

moojd 7y ago

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. Might be worth investigating if you have a ton of JSON.