+bmeurer@ Thanks Seth,
This is a known issue to a certain extent ( bit.ly/v8-investigation-of-class-performance), though I'm not sure we've measured the impact of the issue on Jetstream specifically. It's a tricky problem -- the object model is optimised for "struct-like" use of objects, rather than "class-like", and it's not obvious how to optimise the latter without sacrificing performance on the former. There are some ideas on the linked doc, I don't think any have been investigated much further than in that doc though. - Leszek On Tue, Jul 30, 2019 at 7:07 AM Jakob Gruber <[email protected]> wrote: > > > On Mon, Jul 29, 2019 at 8:46 PM seth.brenith via v8-dev < > [email protected]> wrote: > >> Hello, >> >> I've recently been looking through the JetStream 2 test suite, and I >> found a pretty interesting behavior in the FlightPlanner >> <https://github.com/WebKit/webkit/blob/master/PerformanceTests/JetStream2/RexBench/FlightPlanner/flight_planner.js> >> benchmark. It defines a class constructor for a class named Leg as follows: >> >> constructor(fix, location) >> { >> this.previous = undefined; >> this.next = undefined; >> this.fix = fix; >> this.location = location; >> this.course = 0; >> this.distance = 0; >> this.trueAirspeed = 0; >> this.windDirection = 0; >> this.windSpeed = 0; >> this.heading = 0; >> this.estGS = 0; >> this.startFlightTiming = false; >> this.stopFlightTiming = false; >> this.engineConfig = EngineConfig.Cruise; >> this.fuelFlow = 0; >> this.distanceRemaining = 0; >> this.estimatedTimeEnroute = undefined; >> this.estTimeRemaining = 0; >> this.estFuel = 0; >> } >> >> >> At a glance, this seems like good code, written following best practices: >> it defines all of the properties for the object, in a consistent order, >> with reasonable default values. However, a bunch of subclasses extend from >> Leg, which makes all of these stores megamorphic. I tried wrapping the >> contents of this constructor with "if (this.constructor === Leg)", and >> copying all of the property-initialization code into the leaf subclass >> constructors, to enforce monomorphic behavior during construction; this >> yielded a 17% improvement to average speed. >> >> Of course, storing properties during construction is only part of the >> problem; there are also many megamorphic loads and stores of these >> properties elsewhere. >> >> This seems like a pretty common case that might have come up previously, >> but I found nothing in a quick search through the bug tracker and v8-dev >> group. Have there been previous discussions, or are there existing design >> docs regarding faster property access when using ES6 class inheritance? >> >> Thanks! >> >> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/15af9604-d1ed-4ce8-a0ff-3e92667739b0%40googlegroups.com >> <https://groups.google.com/d/msgid/v8-dev/15af9604-d1ed-4ce8-a0ff-3e92667739b0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAGRskv_oj%2BHsvx3wp7y6B7vT_0dtbrLjFjpdT3VsqrESo6sd8g%40mail.gmail.com.
