New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users

Issue metadata

Status: Started
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature


Sign in to add a comment

Optimize Speedometer 2.0

Project Member Reported by mathias@chromium.org, Feb 2

Issue description

Benchmark: http://browserbench.org/Speedometer2.0/
Announcement: https://webkit.org/blog/8063/speedometer-2-0-a-benchmark-for-modern-web-app-responsiveness/
Chrome/V8 blog post: https://v8project.blogspot.com/2018/01/speedometer-2.html

This is the tracking bug for the issues discovered through the Speedometer 2.0 benchmark.
 
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/808dc8cff3f6530a627ade106cbd814d16a10a18

commit 808dc8cff3f6530a627ade106cbd814d16a10a18
Author: Camillo Bruni <cbruni@chromium.org>
Date: Wed Oct 04 13:06:49 2017

Support fast-path Function.prototype.bind for bound function

This CL speeds up a common pattern found in the React framework:

function f(a, b, c) { ... };
let f_bound = f.bind(this, 1);
let f_bound2 = f_bound(this, 2);

This CL yields roughly a 15× improvement for rebinding a bound function.

Change-Id: I4d8580a5bce422af411148bc6b3e4eb287fac9ce
Reviewed-on: https://chromium-review.googlesource.com/695206
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48283}
[modify] https://crrev.com/808dc8cff3f6530a627ade106cbd814d16a10a18/src/accessors.cc
[modify] https://crrev.com/808dc8cff3f6530a627ade106cbd814d16a10a18/src/builtins/builtins-function-gen.cc
[modify] https://crrev.com/808dc8cff3f6530a627ade106cbd814d16a10a18/src/objects.cc
[modify] https://crrev.com/808dc8cff3f6530a627ade106cbd814d16a10a18/src/objects.h
[modify] https://crrev.com/808dc8cff3f6530a627ade106cbd814d16a10a18/test/mjsunit/function-bind.js
Blockedon: 771227
Blockedon: v8:5988
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/f610be969095d0af8569924e7d7780b5a6a890cd

commit f610be969095d0af8569924e7d7780b5a6a890cd
Author: Adithya Srinivasan <adithyas@chromium.org>
Date: Thu Nov 23 16:24:51 2017

Skip shadow root creation for input types that don't need it

Certain input types like checkboxes and radio buttons don't make use
of the shadow root that is currently created by default. This CL adds
a method to InputTypeView that indicates if an input type needs to
create a shadow root, and skips shadow root creation in
InitializeTypeInParsing if possible.

Bug: 
Change-Id: Id932c06cdd924a5b6006d8770d9cc6d09cb3da82
Reviewed-on: https://chromium-review.googlesource.com/773180
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Hayato Ito <hayato@chromium.org>
Reviewed-by: Keishi Hattori <keishi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518955}
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/core/html/forms/BaseCheckableInputType.h
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/core/html/forms/HTMLInputElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/core/html/forms/HTMLInputElement.h
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/core/html/forms/HTMLInputElementTest.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/core/html/forms/HiddenInputType.h
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/core/html/forms/InputTypeView.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/core/html/forms/InputTypeView.h
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/core/html/forms/TextControlElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/accessibility/AXLayoutObject.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlCastButtonElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlDownloadButtonElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlFullscreenButtonElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlInputElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlInputElementTest.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlMuteButtonElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlOverflowMenuButtonElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlOverlayPlayButtonElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlPlayButtonElement.cpp
[modify] https://crrev.com/f610be969095d0af8569924e7d7780b5a6a890cd/third_party/WebKit/Source/modules/media_controls/elements/MediaControlSliderElement.cpp
third_party/WebKit/Source/modules/media_controls/elements/MediaControlToggleClosedCaptionsButtonElement.cpp
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/6dd09a38aaae9c15adf5aad966f761f180bf1cef

commit 6dd09a38aaae9c15adf5aad966f761f180bf1cef
Author: Lucas Furukawa Gadani <lfg@chromium.org>
Date: Mon Nov 13 18:34:22 2017

Clean up blink::SegmentedString

This CL cleans up and simplifies SegmentedString, leading
to an improvement in parsing performance.

This CL also adds a cache for the current_char_ in SegmentedSubstring,
so it can avoid a branch when calling GetCurrentChar().

Profiling shows a 1.5% improvement in the jQuery benchmark in
Speedometer 2.0 and around 1% across the various VanillaJS benchmarks
in Speedometer 2.0.

Change-Id: Idc1ae1e277aaec1c9f581075eab563fcd2a72688
Reviewed-on: https://chromium-review.googlesource.com/762016
Commit-Queue: Lucas Gadani <lfg@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515989}
[modify] https://crrev.com/6dd09a38aaae9c15adf5aad966f761f180bf1cef/third_party/WebKit/Source/platform/text/SegmentedString.cpp
[modify] https://crrev.com/6dd09a38aaae9c15adf5aad966f761f180bf1cef/third_party/WebKit/Source/platform/text/SegmentedString.h
[modify] https://crrev.com/6dd09a38aaae9c15adf5aad966f761f180bf1cef/third_party/WebKit/Source/platform/text/SegmentedStringTest.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/a4af0ce633c5032bafc55e86248c9a78634ef8f8

commit a4af0ce633c5032bafc55e86248c9a78634ef8f8
Author: Camillo Bruni <cbruni@chromium.org>
Date: Sat Nov 18 00:52:12 2017

[ic] Track the IC state change in FeedbackNexus::ConfigureMegamorphic

- This precents us from logging two ICEvents for a megamorphic miss that adds
  a new property
- We don't have to reset the profiler ticks anymore for this miss

The particular case for missing to add a new property happens ~1700 times in
the Speedometer Angular benchmark where we get an already internalized key
as property name.

Change-Id: I2362c3b7a66d9def1bc4295f6f1e64c96b25fe8a
Reviewed-on: https://chromium-review.googlesource.com/777259
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49464}
[modify] src/feedback-vector.cc
[modify] src/feedback-vector.h
[modify] src/ic/ic.cc
[modify] src/ic/ic.h
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/6366a010080ec106ad83964060825c0a72c77458

commit 6366a010080ec106ad83964060825c0a72c77458
Author: Benedikt Meurer <bmeurer@chromium.org>
Date: Thu Nov 02 10:14:07 2017

[ic] Internalize strings on the fly in KeyedLoadICGeneric.

This turns on the existing --internalize_on_the_fly flag for the
MEGAMORPHIC KeyedLoadIC to properly internalize strings before
looking up the property. This avoids the otherwise taken runtime
call to %KeyedGetProperty, which is definitely slower.

Initially the --internalize_on_the_fly flag was turned off because
internalizing strings on the fly causes too much traffic on the
megamorphic stub cache. We avoid this problem here by not probing
the stub cache in that case, which still gives the benefit of not
having to go to the runtime.

This improves the babylon test on the web-tooling-benchmark by around
2-3% and will probably also help with several tests (like React or
Ember) on the Speedometer benchmark.

If this CL causes trouble (i.e. tanks something important), we can
just turn off the --internalize_on_the_fly flag again.

Bug: v8:6936,  v8:7026 
Change-Id: Ia59a8a3799d9624d831d66b05bae3ecef31cee0a
Reviewed-on: https://chromium-review.googlesource.com/750821
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49072}
[modify] https://crrev.com/6366a010080ec106ad83964060825c0a72c77458/src/flag-definitions.h
[modify] https://crrev.com/6366a010080ec106ad83964060825c0a72c77458/src/ic/accessor-assembler.cc
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/b7168573ed011113746873fd92b71e8bcc9dddb1

commit b7168573ed011113746873fd92b71e8bcc9dddb1
Author: Benedikt Meurer <bmeurer@chromium.org>
Date: Fri Nov 03 07:35:14 2017

[turbofan] Generalized OOB support for KeyedLoadIC.

This extends the support in TurboFan and the ICs for OOB loads to also
apply to typed arrays and receivers whose prototype chain is protected
by the "no elements" protector (aka the Array protector). TurboFan will
generate code to materialize undefined instead when it sees a load that
has the OOB bit set and add an appropriate code dependency on the global
protector. For typed arrays it doesn't even need to check the global
protector since elements are never looked up in the prototype chain
for typed arrays.

In the simple micro-benchmark from the bug we go from

  testInBounds: 103 ms.
  testOutOfBounds: 289 ms.

to

  testInBounds: 103 ms.
  testOutOfBounds: 102 ms.

which fixes the 3x slowdown and thus addresses the performance cliff. In
general it's still beneficial to make sure that you don't access out of
bounds, especially once we introduce a bounds check elimination pass to
TurboFan.

This also seems to improve the jQuery benchmark on the Speedometer test
suite by like 1-2% on average. And the SixSpeed rest benchmarks go from

  rest-es5: 25 ms.
  rest-es6: 23 ms.

to

  rest-es5: 6 ms.
  rest-es6: 4 ms.

so a solid 5.7x improvement there.

Bug: v8:6936,  v8:7014 ,  v8:7027 
Change-Id: Ie99699c69cc40057512e72fd40ae28107216c423
Reviewed-on: https://chromium-review.googlesource.com/750089
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49095}
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/code-stub-assembler.cc
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/compiler/js-native-context-specialization.cc
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/compiler/js-native-context-specialization.h
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/feedback-vector.cc
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/ic/accessor-assembler.cc
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/ic/handler-configuration-inl.h
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/ic/handler-configuration.cc
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/ic/handler-configuration.h
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/ic/ic.cc
[modify] https://crrev.com/b7168573ed011113746873fd92b71e8bcc9dddb1/src/ic/ic.h

Blockedon: v8:7014
Blockedon: v8:7027
Blockedon: v8:6702
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/06753c64eba67975e3f705dc0c4e05a68cc3b82a

commit 06753c64eba67975e3f705dc0c4e05a68cc3b82a
Author: Benedikt Meurer <bmeurer@chromium.org>
Date: Mon Aug 28 06:00:47 2017

[turbofan] Optimize O.p.hasOwnProperty inside for-in.

Optimize the common pattern

  for (var i in o) {
    if (Object.prototype.hasOwnProperty.call(o, i)) {
      // do something
    }
  }

which is part of the guard-for-in style in ESLint (see the documentation
at https://eslint.org/docs/rules/guard-for-in for details). This pattern
also shows up in React and Ember applications quite a lot (and is tested
by the appropriate Speedometer benchmarks, although not dominating those
benchmarks, since they spent a lot of time in non-TurboFan'ed code).

This improves the forInHasOwnProperty and forInHasOwnPropertySafe micro-
benchmarks in v8:6702, which look like this

  function forInHasOwnProperty(o) {
    var result = 0;
    for (var i in o) {
      if (o.hasOwnProperty(i)) {
        result += 1;
      }
    }
    return result;
  }

  function forInHasOwnPropertySafe(o) {
    var result = 0;
    for (var i in o) {
      if (Object.prototype.hasOwnProperty.call(o, i)) {
        result += 1;
      }
    }
    return result;
  }

by around 4x and allows for additional optimizations in the future, by
also elimiating the megamorphic load when accessing the enumerated
properties.

This changes the interpreter ForInNext bytecode to collect more precise
feedback about the for-in state, which now consists of three individual
states: UNINITIALIZED, MEGAMORPHIC and GENERIC. The MEGAMORPHIC state
means that the ForInNext has only seen objects with a usable enum cache
thus far, whereas GENERIC means that we have seen some slow-mode for..in
objects as well.

R=jarin@chromium.org

Bug:   v8:6702  
Change-Id: Ibcd75ea9b58c3b4f9219f11bc37eb04a2b985604
Reviewed-on: https://chromium-review.googlesource.com/636964
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47632}
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/bootstrapper.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/builtins/builtins-definitions.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/builtins/builtins-object-gen.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/access-builder.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/access-builder.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/bytecode-graph-builder.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/bytecode-graph-builder.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/effect-control-linearizer.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/effect-control-linearizer.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/js-call-reducer.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/js-call-reducer.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/js-type-hint-lowering.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/js-type-hint-lowering.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/js-typed-lowering.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/opcodes.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/simplified-lowering.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/simplified-operator.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/simplified-operator.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/typer.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/compiler/verifier.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/debug/debug-evaluate.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/deoptimize-reason.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/feedback-vector-inl.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/feedback-vector.cc
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/feedback-vector.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/heap-symbols.h
[modify] https://crrev.com/06753c64eba67975e3f705dc0c4e05a68cc3b82a/src/interpreter/interpreter-generator.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/f1ec44e2f525434b7af60450aa7678d12b519aee

commit f1ec44e2f525434b7af60450aa7678d12b519aee
Author: Benedikt Meurer <bmeurer@chromium.org>
Date: Fri Sep 01 11:27:37 2017

[turbofan] Optimize fast enum cache driven for..in.

This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like

  for (var k in o) {
    var v = o[k];
    // ...
  }

and code like

  for (var k in o) {
    if (Object.prototype.hasOwnProperty.call(o, k)) {
      var v = o[k];
      // ...
    }
  }

which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.

For example the micro-benchmark in the tracking   bug v8:6702   now runs
faster than ever before:

 forIn: 1516 ms.
 forInHasOwnProperty: 1674 ms.
 forInHasOwnPropertySafe: 1595 ms.
 forInSum: 2051 ms.
 forInSumSafe: 2215 ms.

Compared to numbers from V8 5.8 which is the last version running with
Crankshaft

 forIn: 1641 ms.
 forInHasOwnProperty: 1719 ms.
 forInHasOwnPropertySafe: 1802 ms.
 forInSum: 2226 ms.
 forInSumSafe: 2409 ms.

and V8 6.0 which is the current stable version with TurboFan:

 forIn: 1713 ms.
 forInHasOwnProperty: 5417 ms.
 forInHasOwnPropertySafe: 5324 ms.
 forInSum: 7556 ms.
 forInSumSafe: 11067 ms.

It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.

For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.

This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.

Bug:   v8:6702  
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/BUILD.gn
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/ast/ast.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/builtins/builtins-definitions.h
[delete] https://crrev.com/6d249930b37b985d534e9cfcbf0b854701d98935/src/builtins/builtins-forin-gen.cc
[delete] https://crrev.com/6d249930b37b985d534e9cfcbf0b854701d98935/src/builtins/builtins-forin-gen.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/builtins/builtins-internal-gen.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/code-stub-assembler.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/code-stub-assembler.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/access-builder.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/access-builder.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/bytecode-graph-builder.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/bytecode-graph-builder.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/common-operator.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/effect-control-linearizer.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/effect-control-linearizer.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-call-reducer.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-generic-lowering.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-native-context-specialization.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-native-context-specialization.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-operator.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-operator.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-type-hint-lowering.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-type-hint-lowering.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-typed-lowering.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/js-typed-lowering.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/opcodes.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/operator-properties.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/simplified-lowering.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/simplified-operator.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/simplified-operator.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/typer.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/compiler/verifier.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/debug/debug-evaluate.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/feedback-vector-inl.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/feedback-vector.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/feedback-vector.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/globals.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/interpreter/bytecode-array-builder.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/interpreter/bytecode-array-builder.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/interpreter/bytecode-generator.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/interpreter/bytecodes.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/interpreter/interpreter-generator.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/objects-printer.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/runtime/runtime-forin.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/runtime/runtime.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/runtime/runtime.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/type-hints.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/type-hints.h
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/src/v8.gyp
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/test/cctest/interpreter/bytecode_expectations/ForIn.golden
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/test/cctest/interpreter/bytecode_expectations/WideRegisters.golden
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/test/cctest/test-feedback-vector.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/test/unittests/interpreter/bytecode-array-builder-unittest.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/test/unittests/interpreter/bytecode-array-iterator-unittest.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/test/unittests/interpreter/bytecode-array-random-iterator-unittest.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/test/unittests/interpreter/bytecode-array-writer-unittest.cc
[modify] https://crrev.com/f1ec44e2f525434b7af60450aa7678d12b519aee/test/unittests/interpreter/bytecode-decoder-unittest.cc


Blockedon: v8:6278
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/426ae4265e539da2932ea2cb2cc1aeed97788b41

commit 426ae4265e539da2932ea2cb2cc1aeed97788b41
Author: Benedikt Meurer <bmeurer@chromium.org>
Date: Thu Aug 03 06:13:13 2017

[csa] Extend TryToName to also implicitly convert Oddball keys.

Previously TryToName bailed out for Oddball keys (i.e. when passing true
or false as the key), which meant that for example the generic
KeyedLoadIC would always bail out to the %KeyedGetProperty runtime
function. But handling Oddball keys is fairly easy, since every oddball
value carries it's unique string representation. Adding just this case
to the CodeStubAssembler::TryToName method boosts this simple
micro-benchmark by a factor of 4x:

  const n = 1e7;
  const obj = {};
  const key = true;

  console.time('foo');
  for (let i = 0; i < n; ++i) {
    if (obj[key] === undefined) {
      obj[key] = key;
    }
  }
  console.timeEnd('foo');

It also shows on the ARES-6 ML benchmark and on several Speedometer
tests, where objects are being used as dictionaries and the developers
rely on the implicit ToString conversions on the property accesses.
In the ARES-6 ML benchmark, the number of calls to %KeyedGetProperty
is reduced by 137,758.

Bug:  v8:6278 , v8:6344, v8:6670
Change-Id: Iaa965e30be4c247682a67ec09543655df9b761d2
Reviewed-on: https://chromium-review.googlesource.com/599527
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47105}
[modify] https://crrev.com/426ae4265e539da2932ea2cb2cc1aeed97788b41/src/code-stub-assembler.cc
[modify] https://crrev.com/426ae4265e539da2932ea2cb2cc1aeed97788b41/test/cctest/test-code-stub-assembler.cc

Blockedon: v8:6654
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e

commit 31800120ccb215cdd1b6b1bde7fd05ecf72ee16e
Author: Benedikt Meurer <bmeurer@chromium.org>
Date: Tue Aug 01 09:30:44 2017

[builtins] Speed-up Object.prototype.toString.

The @@toStringTag lookup in Object.prototype.toString causes quite a
lot of overhead and oftentimes dominates the builtin performance. These
lookups are almost always negative, especially for primitive values,
and Object.prototype.toString is often used to implement predicates
(like in Node core or in AngularJS), so having a way to skip the
negative lookup yields big performance gains.

This CL introduces a "MayHaveInterestingSymbols" bit on every map,
which says whether instances with this map may have an interesting
symbol. Currently only @@toStringTag is considered an interesting
symbol, but we can extend that in the future.

In the Object.prototype.toString we can use the interesting symbols
bit to do a quick check on the prototype chain to see if there are
any maps that might have the @@toStringTag, and if not, we can just
immediately return the result, which is very fast because it's derived
from the instance type. This also avoids the ToObject conversions for
primitive values, which is important, since this causes unnecessary
GC traffic and in for example AngularJS, strings are also often probed
via the Object.prototype.toString based predicates.

This boosts Speedometer/AngularJS by over 3% and Speedometer overall
by up to 1%. On the microbenchmark from the similar SpiderMonkey bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=1369042), we go from
roughly 450ms to 70ms, which corresponds to a 6.5x improvement.

```
function f() {
    var res = "";
    var a = [1, 2, 3];
    var toString = Object.prototype.toString;
    var t = new Date;
    for (var i = 0; i < 5000000; i++)
	res = toString.call(a);
    print(new Date - t);
    return res;
}
f();
```

The design document at https://goo.gl/e8CruQ has some additional
data points.

TBR=ulan@chromium.org

Bug:   v8:6654  
Change-Id: I31932cf41ecddad079d294e2c322a852af0ed244
Reviewed-on: https://chromium-review.googlesource.com/593620
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47034}
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/api-natives.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/bootstrapper.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/builtins/builtins-definitions.h
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/builtins/builtins-object-gen.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/code-stub-assembler.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/code-stub-assembler.h
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/debug/debug-evaluate.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/factory.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/heap/heap.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/objects-debug.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/objects-inl.h
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/objects-printer.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/objects.cc
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/objects/map.h
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/objects/name-inl.h
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/src/objects/name.h
[modify] https://crrev.com/31800120ccb215cdd1b6b1bde7fd05ecf72ee16e/test/cctest/test-code-stub-assembler.cc

commit 6a75fcd4df042f9c1d93319d92d69d72386d8419
Author: Benedikt Meurer <bmeurer@chromium.org>
Date:   Thu Jul 27 12:46:33 2017 +0200

    [ignition] Improve code generation for TestTypeOf.

    The code generated for the TestTypeOf bytecode was not ideal, mostly
    because of the default case that just aborted. If we do CSA_ASSERT to
    check the validity of the literal_flag instead anf then just use the
    last label as the default, the bytecode handler no longer builds a
    stack frame and generated code quality is now really close to ideal.

    The TestTypeOf bytecode handler was found to be among the three
    hottest bytecode handlers in the Speedometer/AngularJS benchmark.

    R=jarin@chromium.org

    Change-Id: I47705a0ca0a436d5c42899001064e77d44845a64
    Reviewed-on: https://chromium-review.googlesource.com/589207
    Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
    Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46930}
Blockedon: 708103
commit ac99f28a6372c5dbd2486f8fd21edef4a4b20b64
Author: Jeremy Roman <jbroman@chromium.org>
Date:   Fri Oct 27 15:14:02 2017 +0000

    Remove id attribute from inner editor element.

    This forces the UA shadow root to create a number of data structures, and for
    this use case they are adequately replaced by a single native Oilpan member.

    On my workstation, this shows up as using about 1.3% of the CPU time in the
    Speedometer jQuery TodoMVC app.

    Change-Id: I5de4fcbd86920f447399c07f57d5b0f382a3216b
    Reviewed-on: https://chromium-review.googlesource.com/734233
    Commit-Queue: Jeremy Roman <jbroman@chromium.org>
    Reviewed-by: Keishi Hattori <keishi@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#512185}
Should issue 792495 & issue 784025 be considered blocker of this as well?
commit 10e32c0672ba494d9004bf5a32e1f45849e4148a
Author: Adithya Srinivasan <adithyas@chromium.org>
Date:   Fri Feb 2 01:18:11 2018 +0000

    Change most kTreeScope collections to be of type kNode
    
    All these caches only return nodes that are in the Document tree. They
    only need invalidation when a changed node is in/previously in
    the Document tree, so they don't need to be separately invalidated
    at the Document level. They will automatically be invalidated when the
    ancestors of a node are invalidated in
    InvalidateNodeListCachesInAncestors, because the Document is an
    ancestor.
    
    Change-Id: I3da315c77e0afe8c82822ea25b8df8099535eded
    Reviewed-on: https://chromium-review.googlesource.com/890704
    Reviewed-by: Kent Tamura <tkent@chromium.org>
    Reviewed-by: Kentaro Hara <haraken@chromium.org>
    Reviewed-by: Hayato Ito <hayato@chromium.org>
    Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#533888}

Cc: rmcilroy@chromium.org
Cc: cbruni@chromium.org
Cc: adithyas@chromium.org jbroman@chromium.org lfg@chromium.org
Blockedon: v8:7555
Blockedon: 819738
Project Member

Comment 26 by bugdroid1@chromium.org, Mar 15

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe

commit 6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe
Author: Lucas Gadani <lfg@chromium.org>
Date: Thu Mar 15 05:36:46 2018

Inline Node::RareData.

This leads to a ~0.3% overall improvement on the speedometer
2.0 benchmark, with a ~1% improvement on the jQuery framework's
TodoMVC implementation in speedometer.

Bug: 808503
Change-Id: I0a24121585cb3d68cbd8cf47d7b75bd3612997b8
Reviewed-on: https://chromium-review.googlesource.com/957622
Commit-Queue: Lucas Gadani <lfg@chromium.org>
Reviewed-by: Hayato Ito <hayato@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543308}
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/ContainerNode.cpp
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/ContainerNode.h
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/Element.cpp
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/Element.h
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/ElementRareData.h
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/Node.cpp
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/Node.h
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/NodeRareData.cpp
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/NodeRareData.h
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/dom/TreeScopeAdopter.cpp
[modify] https://crrev.com/6f2cdb6210cd7c04edad9c1f857ac3039f2b4abe/third_party/WebKit/Source/core/html/forms/LabelableElement.cpp

Project Member

Comment 27 by bugdroid1@chromium.org, Apr 10

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/348d23ce26e25195a70f0be40f88d72b8fad0955

commit 348d23ce26e25195a70f0be40f88d72b8fad0955
Author: Adithya Srinivasan <adithyas@chromium.org>
Date: Tue Apr 10 13:51:41 2018

Skip layout if possible in Element.focus

This CL adds a way to check if an element is focusable without
requiring layout to be up to date. This allows us to skip doing a full
layout for elements that aren't focusable.

Bug: 808503
Change-Id: I9cbcde28262039e908aac6cbc9ce00a057320c30
Reviewed-on: https://chromium-review.googlesource.com/955544
Reviewed-by: Kent Tamura <tkent@chromium.org>
Reviewed-by: Alan Cutter <alancutter@chromium.org>
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549511}
[modify] https://crrev.com/348d23ce26e25195a70f0be40f88d72b8fad0955/third_party/WebKit/LayoutTests/platform/mac/paint/invalidation/forms/textarea-caret-expected.txt
[modify] https://crrev.com/348d23ce26e25195a70f0be40f88d72b8fad0955/third_party/blink/renderer/core/dom/document.cc
[modify] https://crrev.com/348d23ce26e25195a70f0be40f88d72b8fad0955/third_party/blink/renderer/core/dom/element.cc
[modify] https://crrev.com/348d23ce26e25195a70f0be40f88d72b8fad0955/third_party/blink/renderer/core/dom/element.h
[modify] https://crrev.com/348d23ce26e25195a70f0be40f88d72b8fad0955/third_party/blink/renderer/core/editing/ime/input_method_controller.cc

Sign in to add a comment