New issue
Advanced search Search tips

Issue 823958 link

Starred by 1 user
Status: Fixed
Owner: ----
Closed: Apr 2018
Cc:
pdr@chromium.org
wangxianzhu@chromium.org
chrishtr@chromium.org
vmp...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocking:
issue 803867



Sign in to add a comment

Optimize PaintChunksToCcLayer.cpp ConversionContext::Convert

Project Member Reported by pdr@chromium.org, Mar 21 2018 
We have a SPV175 regression on Compositing.Renderer.LayersUpdateTime.[0-4]:
https://uma.googleplex.com/p/chrome/variations/?sid=71bdcf35b43dc2a4416e7fcf80b5d4f7

This can be explained by ConversionContext::Convert. We have a microbenchmark of this code, blink_perf.paint color-changes.html, but this code does not show up in the PrePaint or Paint times of the benchmark (i.e., only look at this test in a profiler, do not consider the results). In a profiler, this function has a lot of self-time, so I think it may be improvable. Improvements to this code will show up in the LayersUpdateTime finch results.

This bug should track targeted performance improvements to this code.

Comment 1 by pdr@chromium.org, Mar 21 2018 

Here's a comparison of !SPV175 (left) vs SPV175 (right) on the color-changes.html microbenchmark.

Notable differences:
SPV175 spends a lot of self-time in PaintChunksToCcLayer:
3.15s in PaintChunksToCcLayer
2.99s in ChunkToLayerMapper::MapVisualRect (called from PaintChunksToCcLayer)

The equivalent !SPV175 codepath is:
3.44s in DrawingDisplayItem::AppendToWebDisplayItemList
1.48s in WebDisplayItemListImpl::AppendDrawingItem



SPV175 spends a lot of time in paint doing raster invalidation in Paint, and a little less time in PrePaint:
2.87s generating raster invalidations (Paint)
1.2s in PaintController::ProcessNewItem (Paint)
1.50s in PaintInvalidator::InvalidatePaint (PrePaint)
2.07s in PrePaintTreeWalk::Walk (PrePaint)

The !SPV175 codepath does raster invalidation in PrePaint, but that adds very little in this benchmark:
0.8s is spent in PaintController::ProcessNewItem (Paint)
1.57s in PaintInvalidator::InvalidatePaint (PrePaint)
2.27s in PrePaintTreeWalk::Walk (PrePaint)
profile_comparison.png
1.3 MB View Download

Comment 2 by wangxianzhu@chromium.org, Mar 21 2018 

What are the total time of PaintChunksToCcLayer (SPv175) and AppendToWebDisplayItemList (!SPv175), and PrePaint (both SPv175 and !SPv175)?

This case seems a one of the extreme cases of SPv175 regression and worth investigation.

For average, the current Finch result shows near zero PrePaint+Paint regression (unweighted). If weighted with the number of PrePaints and Paints, there will be a progression.

Comment 3 by pdr@chromium.org, Mar 21 2018 

I realized I missed some raster invalidation work in CommitNewDisplayItems in the above post, but the difference isn't large.

SPV175 total time:
PaintChunksToCcLayer: 5.37s - 7.2%
PrePaint: 3.02s - 4.0%
Paint: 13.19s - 17.8%

!SPV175 total time:
AppendToWebDisplayItemList: 4.42s - 5.9%
PrePaint: 4.10s - 5.5%
Paint: 10.75s - 14.4%

Comment 4 by wangxianzhu@chromium.org, Apr 12 2018

Status: Fixed (was: Available)
After the recent optimization CLs, now record_time regression on ct has dropped below 5% (which was 46% when we first started to test performance on ct). Given that PaintChunksToCcLayer is more complex than AppendToWebDisplayItemList, I think the current status is satisfactory. Finch (go/spv175status) shows overall improvement of spv175.
►

Sign in to add a comment