Changeset 221106 in webkit


Ignore:
Timestamp:
Aug 23, 2017 2:40:41 PM (7 years ago)
Author:
rniwa@webkit.org
Message:

Speedometer 2.0: Async time is not always capturing layout time
https://bugs.webkit.org/show_bug.cgi?id=175871

Reviewed by Simon Fraser.

Speedometer harness was designed to capture the time browser engine spends relayouting and repainting the content
after DOM mutations this in its async time measurement, which is the time between each test case's code had finished
running and when a newly scheduled 0s timer is fired immediately afterwards.

It turns out that modern web browsers defer this reflow and repaint work until the next animation frame is requested.
This results in Speedometer harness measuring reflow and repaint cost only sometimes depending on when each test case
had finished running relative to the next frame request.

While such a behavior makes sense and might be desirable for a modern browser engine, we would like to capture it in
the async time for the purpose of Speedometer. Unfortunately, there isn't an interoperable API for browsers to report
the total layout and repaint time, and relying on 16ms-granularity requestAnimationFrame is too coarse for Speedometer.

This patch works around these limitations by manually forcing the layout in async time measurement by calling
getBoundingClientRect() in iframe's document. Since the height of the document depends on the number of todo items,
this should cause browser engines to do most if not all of the work needed to reflow the document at least for now.

Note that even new async time doesn't always capture painting time but there isn't a good cross-browser mechanism
to measure paint time in the granurality we need for Speedometer at the moment anyway. (Should such a mechanism exist,
that could be a huge timing attack surface so it's probably best that we don't have one.)

  • Speedometer/resources/benchmark-runner.js:

(BenchmarkRunner.prototype._runTest):

Location:
trunk/PerformanceTests
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/PerformanceTests/ChangeLog

    r221105 r221106  
     12017-08-23  Ryosuke Niwa  <rniwa@webkit.org>
     2
     3        Speedometer 2.0: Async time is not always capturing layout time
     4        https://bugs.webkit.org/show_bug.cgi?id=175871
     5
     6        Reviewed by Simon Fraser.
     7
     8        Speedometer harness was designed to capture the time browser engine spends relayouting and repainting the content
     9        after DOM mutations this in its async time measurement, which is the time between each test case's code had finished
     10        running and when a newly scheduled 0s timer is fired immediately afterwards.
     11
     12        It turns out that modern web browsers defer this reflow and repaint work until the next animation frame is requested.
     13        This results in Speedometer harness measuring reflow and repaint cost only sometimes depending on when each test case
     14        had finished running relative to the next frame request.
     15
     16        While such a behavior makes sense and might be desirable for a modern browser engine, we would like to capture it in
     17        the async time for the purpose of Speedometer. Unfortunately, there isn't an interoperable API for browsers to report
     18        the total layout and repaint time, and relying on 16ms-granularity requestAnimationFrame is too coarse for Speedometer.
     19
     20        This patch works around these limitations by manually forcing the layout in async time measurement by calling
     21        getBoundingClientRect() in iframe's document. Since the height of the document depends on the number of todo items,
     22        this should cause browser engines to do most if not all of the work needed to reflow the document at least for now.
     23
     24        Note that even new async time doesn't always capture painting time but there isn't a good cross-browser mechanism
     25        to measure paint time in the granurality we need for Speedometer at the moment anyway. (Should such a mechanism exist,
     26        that could be a huge timing attack surface so it's probably best that we don't have one.)
     27
     28        * Speedometer/resources/benchmark-runner.js:
     29        (BenchmarkRunner.prototype._runTest):
     30
    1312017-08-23  Ryosuke Niwa  <rniwa@webkit.org>
    232
  • trunk/PerformanceTests/Speedometer/resources/benchmark-runner.js

    r220950 r221106  
    137137    var startTime = now();
    138138    setTimeout(function () {
     139        // Some browsers don't immediately update the layout for paint.
     140        // Force the layout here to ensure we're measuring the layout time.
     141        var height = self._frame.contentDocument.body.getBoundingClientRect().height;
    139142        var endTime = now();
     143        self._frame.contentWindow._unusedHeightValue = height; // Prevent dead code elimination.
    140144        self._writeMark(suite.name + '.' + test.name + '-async-end');
    141         callback(syncTime, endTime - startTime);
     145        callback(syncTime, endTime - startTime, height);
    142146    }, 0);
    143147}
Note: See TracChangeset for help on using the changeset viewer.