https://codereview.chromium.org/2430313004/ paints all collapsed borders of a table in one display item to avoid the visual rect issue of cell collapsed borders.
About its performance:
On 2016/11/07 23:35:50, Xianzhu wrote:
> On 2016/11/07 23:25:24, wkorman wrote:
> > On 2016/11/03 15:46:09, Xianzhu wrote:
> > > Added in descriptions. I ran blink_perf.paint perf suite which runs tests
> > under
> > > third_party/WebKit/PerformanceTests/Paint which contains test cases
> specially
> > > for huge tables with collapsed borders which are representative for our
> case.
> >
> > I looked at these tests briefly with chrishtr@ just now, and one question I
> had
> > was whether table row/cols of 300x320 is large enough to reveal performance
> > impact of this change. What do you think? I had assumed "huge" was likely 1K -
> > 10K+.
>
> Will try.
Tried 1kx1k tables. This is near the upper limit that we can test, because the first frame already takes 10~25s. Larger numbers will cause non-responsive page notice.
Results:
Test Without patch With patch
large-table-background-change-with-invisible-collapsed-borders.html 0.29s 0.27s
large-table-background-change-with-visible-collapsed-borders.html 1.1s 0.3s
large-table-collapsed-border-change-with-backgrounds.html 2.3s 2.4s
large-table-collapsed-border-change-with-text.html 0.9s 1.2s
large-table-collapsed-border-change.html 1.5s 2.3s
large-table-repaint.html 2.3s 2.2s
Summary:
- Progression when there is no change to collapsed borders;
- Regression when border changed on a single cell.
- With the bigger table cells (large-table-collapsed-border-change-with-text.html), performance improves in the similar scale with and without patch
Attached traces of large-table-collapsed-border-change.html with and without patch.
Comparison:
- Times for first styling (2.4s vs 2.1s), first layout (4.3s vs 4.2s), first paint invalidation (3.5s vs 3.4s) are similar with and without patch.
- First paint (0.85s vs 1.9s), patch wins.
- Subsequent paints (0.75s vs 0.52s), master wins.
- Rasterization: master won. With patch, the frame time is bound with rasterization. All of the 4 tile workers are fully busy. On master, The tile workers are about 90% idle.
Rasterization regression is the biggest issue of such huge display items. Rasterization regression might be bigger if the table contains more complex contents that don't change.
Will look into this more.
|
Deleted:
trace_large-table-collapsed-borders-change-with-patch.json.gz
2.7 MB
|
|
|
trace_large-table-collapsed-borders-change-with-patch.json.gz
2.7 MB
Download
|
|
|
Deleted:
trace_large-table-collapsed-borders-change-master.json.gz
2.5 MB
|
|
|
trace_large-table-collapsed-borders-change-master.json.gz
2.5 MB
Download
|
Comment 1 by bugdroid1@chromium.org
, Nov 11 2016