Deltablue consists out of two parts: - chainTest - projectionTest On both parts tested separately we are close to V8. But when combining we loose speed. I already did some investigating. When projectionTest is run before chainTest (even only once), the performance of chainTest will go down. That is because we loose the types for the function - BinaryConstraint.prototype.markUnsatisfied - Plan.prototype.addConstraint Both normally have only 3-4 objects as input, but suddenly they are transformed in an AnyObject, with no real reason. I've pinpointed when it happens to: #0 this.removePropagateFrom #1 Plan.prototype.addConstraint #2 planner.incrementalRemove #3 edit.destroyConstraint #4 change #5 projectionTest This only happens with IonMonkey

When looking deeper into it, this is probably related to the extra TypeObjects that are added to the SSA information. chainTest and projectionTest use the same functions, but with other objects. I.e. when running a part separately the inputs to a function is a specific TypeObject. When running both, there are now 2 TypeObjects. I.e. we can't optimize that much. I think bug 804676 (rm ScriptAnalysis::analyzeTypes) could possible make it possible to improve the situation. Than we can reason about types in IM and maybe see that a callsite only uses a specific TypeObject and when inlining only use the intersection between caller types and callee types to optimize the inlined function.

At max this would be a win of 10% on v8-deltablue. This is measured by duplicating all functions to be different between chainTest and projectionTest.

There was a 10% improvement on v8-deltablue due to bug 804676. I thought this would be related to this bug, since now we only look at the callers typeset and not to callees typeset anymore. This isn't the case. I redid the experiment and duplicated all functions different between chainTest and projectionTest and found out it increase the potential of this bug. This can now be a potential 20% improvement.