Comment #25 on issue 2935 by [email protected]: Poor performance in Ember
app Discourse
https://code.google.com/p/v8/issues/detail?id=2935
I updated v8:3664 with a prototype fix, which reduces number of
deoptimizations caused by weak references. To see noticeable performance
improvement we need to also fix v8:3663, otherwise there are many
deoptimizations caused by high degree of polymorphism. Not clearing ICs
would allow generated code to reach the slow generic case faster and thus
avoid deoptimizations. This however is a big project (several months) as it
requires support for weak references in polymorphic ICs to avoid memory
leaks.
In case anyone is wondering why there is high degree of polymorphism.
Stefan and I discussed this offline. Here is what we found out in “Complex
List” benchmark:
EachHelper generates new short living classes for each render. Stack trace:
makeCtor (ember.1.8.0.js:33674)
extend (ember.1.8.0.js:34036)
collectionHelper (ember.1.8.0.js:8319)
eachHelper (ember.1.8.0.js:8912)
(anonymous function) (VM1610:61)
__exports__.template (handlebars-v1.3.0.js:436)
CoreView.extend.render (ember.1.8.0.js:40441)
EmberRenderer_createElement (ember.1.8.0.js:37691)
Renderer_renderTree (ember.1.8.0.js:10337)
V8 creates a hidden class for each of these Ember classes, which leads to
high polymorphism in rendering and view functions. When these short-living
classes die, they cause deoptimization in all code that was optimized for
them.
The hot Class() function is polymorphic in initProperties:
https://github.com/emberjs/ember.js/blob/master/packages/ember-runtime/lib/system/core_object.js#L115-L117
Since initProperties can have arbitrary shape, V8 deoptimizes this function
a lot.
The meta objects are initialized inconsistently and form complex prototype
chains, which results in many hidden classes:
https://github.com/emberjs/ember.js/blob/master/packages/ember-metal/lib/utils.js#L311-L313
In these cases, if instead of tailoring optimized code for a small set of
hidden classes, V8 would emit slow generic code, that would give better
performance by avoiding costly optimizations and deoptimizations. I think
this also explains why performance difference on Android is bigger than
performance difference on desktop. Since Android devices are slower than
desktop, the relative cost of optimization/deoptimization on Android is
higher.
We have ideas on how to handle these cases better in V8, but there is no
quick fix.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
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].
For more options, visit https://groups.google.com/d/optout.
