Closed Bug 1143064 Opened 9 years ago Closed 6 years ago

A simple cache for decision results during BuildDisplayList

Categories

(Core :: Layout, defect)

x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1342009

People

(Reporter: sinker, Unassigned)

References

Details

Attachments

(2 files, 2 obsolete files)

Attached patch POC patch (obsolete) — Splinter Review
This bug is for trying an idea of remembering decision results for BuildDisplayList() to improve the speed of PaintFrame().

BuildDisplayListForChild() decides how to handle displaylist built by a child, by check a lot of variables from frame, parent frame, style context, nsDisplayListBuilder, PresShell ... etc.   It costs a lot of time to check these values, however, for most of time, their results are exactly the same as previous time if the frame stay with the same style, not restyled.  By keeping the result with the frame, it saves a lot of time by reusing the result.

With the POC patch, I get the following numbers
 - With the patch
   - 76.2% 83.7% 77.3% PaintRoot
   - 23.2% 15.3% 21.7% BuildDisplayList
 - Without the patch
   - 71.5% 63.6% 69.2% PaintRoot
   - 28.0% 35.0% 27.9% BuildDisplayList

These numbers were got by doing following steps on a B2G device (flame)
 1. profile.sh start
 2. unlock screen
 3. open twitter app
 4. wait twitter app to load page and all pictures on the screen.
 5. scroll down (swipe) for 1 time
 6. profile.sh capture

3 times for both w/ & w/o the patch.  The numbers are the percentage of CPU time in PaintFrame() function.

In roughly average (not very right way since numbers of samples are not exactly the same).
 - BuildDisplayList / PaintRoot
   - 0.2559940304586661 with the patch
   - 0.4483673492562139 without the patch
It seems to improve a lot.
Attached file profiling data
The numbers are only the part of PaintFrame() called by refresh driver.
More numbers, from first picture to all images loaded.
 - 35xxms w/ the patch
 - 38xxms w/o the patch
Fix minor issues and speed up more.
Attachment #8577327 - Attachment is obsolete: true
Attached patch poc patch v3Splinter Review
rebase to m-c.
Attachment #8579152 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: