As always: when in doubt, measure it! Implement several approaches (in a simplified version of your app if necessary) and see for yourself if any of the options you're considering makes a difference.
Generally I would say that what applies to objects also applies to prototypes (as they're objects too), but your question is too vague to even try to give a precise answer. As Toon said, the key idea that we keep emphasizing is to keep code monomorphic, but you stated that your code relies on polymorphism, so much of the battle is already lost anyway. As for inlining, that's generally at odds with polymorphism -- when you don't know where a call is going, how can you possibly inline it? (Well, you can, but you have to inline all possible targets, which makes it a much tougher tradeoff.) Maybe it doesn't matter if your bottleneck is elsewhere? On Tue, Aug 27, 2013 at 7:50 PM, Toon Verwaest <[email protected]>wrote: > Such optimizations are only true for receivers. If you have different > prototypes all over the place, your code is going is not going to stay > monomorphic. For every distinct prototype there's at least unique hidden > class; given that the prototype link is hardwired in the hidden class. > > regards, > Toon > > > On Tue, Aug 27, 2013 at 6:40 PM, Cris Perdue <[email protected]>wrote: > >> Performance optimization advice from the V8 team emphasizes initializing >> properties to objects in constructors, and always in the same order (for >> example http://www.youtube.com/watch?v=UJPdhx5zTaw). The explanation is >> that this way each instance belongs to the same hidden class. >> >> What if you have fairly computation-intensive code that uses subclassing >> and polymorphism? In this case method lookups need to go through the >> prototype object for the instances. Once execution gets to the >> type-specific method, life should be good again because that code always >> receives a "this" and arguments of the same type at each invocation. (The >> type-specific method code is typically fairly short and quick to execute in >> my software.) >> >> My question is, to what degree should we expect a similar principle to >> apply, that prototypes for subclasses should have the same members and the >> members should be added to each subclass in the same order? Will this make >> the compiler recognize the prototypes as belonging to the same hidden class >> and make a big contribution to fast method lookup? Will method lookup code >> tend to be inlined? Is it OK that the prototypes are all directly instances >> of Object, and not some application-specific class? >> >> Thanks much for any insights here. >> >> -Cris >> > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
