3 ms·

> The only reason to not use microbenchmarks is because you think they will somehow lead you astray and cause you to optimize things such that user experience a

by dwild 7y ago

> The only reason to not use microbenchmarks is because you think they will somehow lead you astray and cause you to optimize things such that user experience actually gets worse. That's not the only reason. It's about putting the effort where it's matters. Sure gaining 30% speed in synthetic benchmark seems great, but if in real world scenario theses things doesn't happen that often (and spoiler alert, they don't), it will means actually much less than 30% of the speed gains. That's not a good metric to go toward. It's simply about investing the development time that you got, where it matters for the user. If your usage is closer to synthetic benchmark and thus you lost close to that 30% of performance since Chrome 75, then take your real world scenario and send that to the V8 teams, I'm sure they'll be happy to consider it in the test suite.

lostmsu 7y ago
Just pondering here: imagine that sites they choose are poorly written, and they spend considerable effort optimizing for these bad patterns. Could it make harder to make a truly performant website for Chrome, because switching to better patters makes your code loose due to them being less optimized in the browser?
- dwild 7y ago
  > Could it make harder to make a truly performant website for Chrome, because switching to better patters makes your code loose due to them being less optimized in the browser? I doubt it would, great pattern aren't just good for humans, they are also much more predictable, and that's quite good for JIT compiler. If it does, I'll just refer to my last sentence which still apply: > If your usage is closer to synthetic benchmark and thus you lost close to that 30% of performance since Chrome 75, then take your real world scenario and send that to the V8 teams, I'm sure they'll be happy to consider it in the test suite.
bradknowles 7y ago
So, use the synthetic benchmark as a regression test. Progress is only counted towards the real world sites, but if you make performance markedly worse on the regression test, then that's a bug.
- dwild 7y ago
  > if you make performance markedly worse on the regression test, then that's a bug. Not at all, it's about not investing time on what doesn't matter. For sure it will means you spend less time on something else and that will slowly get worse. That's why feature get deprecated and removed. Supporting something not used has a cost. I'll repeat my last paragraph: > If your usage is closer to synthetic benchmark and thus you lost close to that 30% of performance since Chrome 75, then take your real world scenario and send that to the V8 teams, I'm sure they'll be happy to consider it in the test suite. If you do need that speed, show them.

by dwild 7y ago

lostmsu 7y ago

Just pondering here: imagine that sites they choose are poorly written, and they spend considerable effort optimizing for these bad patterns. Could it make harder to make a truly performant website for Chrome, because switching to better patters makes your code loose due to them being less optimized in the browser?

dwild 7y ago
> Could it make harder to make a truly performant website for Chrome, because switching to better patters makes your code loose due to them being less optimized in the browser? I doubt it would, great pattern aren't just good for humans, they are also much more predictable, and that's quite good for JIT compiler. If it does, I'll just refer to my last sentence which still apply: > If your usage is closer to synthetic benchmark and thus you lost close to that 30% of performance since Chrome 75, then take your real world scenario and send that to the V8 teams, I'm sure they'll be happy to consider it in the test suite.

bradknowles 7y ago

So, use the synthetic benchmark as a regression test. Progress is only counted towards the real world sites, but if you make performance markedly worse on the regression test, then that's a bug.

dwild 7y ago
> if you make performance markedly worse on the regression test, then that's a bug. Not at all, it's about not investing time on what doesn't matter. For sure it will means you spend less time on something else and that will slowly get worse. That's why feature get deprecated and removed. Supporting something not used has a cost. I'll repeat my last paragraph: > If your usage is closer to synthetic benchmark and thus you lost close to that 30% of performance since Chrome 75, then take your real world scenario and send that to the V8 teams, I'm sure they'll be happy to consider it in the test suite. If you do need that speed, show them.