4 ms·
I'm working with the v8 engine and it's a minefield of de-optimizations and random slowdowns for things that you would not expect to be slow. Exception handler
by mmastrac 3y ago
I'm working with the v8 engine and it's a minefield of de-optimizations and random slowdowns for things that you would not expect to be slow.
Exception handler structures can dramatically change performance characteristics of code. async/await is a real crapshoot -- sometimes promises are faster, sometimes async blocks are.
We can blame the poor specs for some slowdowns (why does `...` destructuring use iterators??), but I wonder if the v8 team is chasing benchmarks at the expense of real-world code that might not be so perfectly written.
- zero_shift 3y ago> why does `...` use iterators?? If you couldn't use the iterator protocol, generators in particular would be a lot less powerful
- mmastrac 3y agoI think the JS spec would have been better served with a different syntax for generator/iterator destructuring. Most code I've seen assumes that: [a, b, ...rest] = array is implemented like this: a = array[0] b = array[1] rest = array[2...] When instead it is a giant performance footgun to the point where it should only be used outside of performance critical code. EDIT "next -> rest"
- postalrat 3y agoI don't assume it's implemented like "next = array[2...]". I don't even know what that means.
- mmastrac 3y agoSorry, I assumed that most people could understand the pseudocode syntax for a subarray operation. In Javascript, this is: array.slice(2)
- depressedpanda 3y agoI understood it, without even thinking about it. In my opinion it's more elegant than the real syntax, and I didn't even realize it wasn't real JavaScript until this comment thread made me look again.
- nightpool 3y agoIs it not able to be specialized like that when the object is a (non-sparse) array? What is preventing engines from making that optimization?
- IainIreland 3y agoIt's possible. We have plans to do so. There are a bunch of finicky corner cases, though. For example, destructuring will call the `return` method of the iterator when it's done (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), so we have to be careful if somebody has defined `return` on the Array iterator prototype. You can supply a default value when destructuring, which is lazily evaluated, so we have to be careful about arbitrary side-effects taking place in the middle of the destructuring. We need to be able to fall back to something less optimized if we suddenly see a generator, or a user-written iterator. And so on. Fundamentally, it's the same thing that impedes most optimizations: there are hundreds of different patterns we could optimize, it takes a fair bit of thought to get it right, and we have finite resources, so we have to pick and choose. This particular pattern turns out to be idiomatic in a lot of React code, which is why we're looking at it now. (Or so people tell me; most JS I write is gross little testcases.)
- zamadatix 3y agoThanks for taking the time to drop these nuggets throughout the thread.
- insanitybit 3y ago> but I wonder if the v8 team is chasing benchmarks at the expense of real-world code that might not be so perfectly written. They aren't. V8's benchmark performance for this benchmark has been stagnant because they haven't cared about it for a long time. Firefox has an incentive to care about it (unfortunately) because even when a benchmark doesn't matter it still looks bad to be behind on it.
- IainIreland 3y agoTo be clear, Firefox doesn't care about this benchmark either. It just so happens that changes we made for Speedometer also improved our performance here, which is a fun coincidence but not important in the grand scheme of things. (Speedometer is the benchmark that most closely approximates messy real-world code.)
- insanitybit 3y agoThanks for clarifying, that's interesting + good to know.
- lossolo 3y ago> but I wonder if the v8 team is chasing benchmarks at the expense of real-world code that might not be so perfectly written. Isn't it the other way around? https://v8.dev/blog/real-world-performance https://v8.dev/blog/real-world-performance I recall there was some newer blogpost discussing this topic with numbers and examples but can't find it atm, maybe it was chromium/chrome team blog, maybe someone else can find it.