Bug 74798 – REGRESSION(r92782): asynchronize and throttle memory cache prune with timer

• Component: WebCore Misc.
• Status: UNCONFIRMED

[Wang Zhongping]

In slideshow of images in large number, webkit memory cache capacity can be exceed quite easily. Starting from 65859 patch (https://bugs.webkit.org/show_bug.cgi?id=65859), memory cache is notified upon decoded data access after each image is drawn. Those notifications result in lots of memory cache prune requests in high frequency. The painting of images are slowed down, because memory cache prune is performed synchronously and it won't return until prune is done.

This patch is to make memory cache prune asynchronous through a Timer and add throttle support to those follow-up requests after timer is scheduled and before it's fired. Timer is scheduled with a delay, either fixed or variable, it's open to design. In this patch, a prune-request-#-per-second related delay is used, to adapt workload change. This patch improves performance by allowing reasonably larger memory cache peak when workload is higher, but it also promises to prune cache timely once timer is fired.

[Wang Zhongping]

Created attachment 119746 [details]
Proposed patch

[Mark Rowe (bdash)]

Traditionally the XYZ in the “REGRESSION(XYZ)” prefix in a bug title refers to a revision number. Putting a bug number in it with no indication that is what the number is can be very confusing.

[Alexey Proskuryakov]

r92782 is Chromium code, and changing cross-platform code to fix an issue that apparently only occurs in one port is something that needs an explanation.

How does this change affect other ports? Can it be tested with an automated regression test?

[Wang Zhongping]

Thanks for your questions. In fact, Chormium change in r92782 has already existed in almost all of the other ports, per ChangeLog of r92782

      "This causes us to call CachedImage::didDraw() which calls CachedResource::didAccessDecodedData() which updates 
        the LRU for decoded image data and potentially prunes the cache. This is already done by almost all of the other ports."

r92782 is to make Chromium behave the same as other ports, so this performance regression issue not only exists in 
Chromium but also exist in other ports (such as cairo, openvg, qt). This patch will also benefit other ports. It can be 
tested with automated regression test.

[Alexey Proskuryakov]

Thank you for the explanation.

> It can be tested with automated regression test.

Please add a test to the patch. We want all testable fixes to come with regression tests. This is particularly important for loader code.

[Wang Zhongping]

Created attachment 120154 [details]
slideshow testcase

This is the testcase from which we find the regression. It has been simplified otherwise it can't be uploaded as attachment due to large size (>20M). Here is a brief description: it consists of 10 rounds of slideshow of 150 images. Round 1 is for warm-up. Round 2-4 is to measure performance when drawing images in full window size, round 5-7 is in raw image size, and round 8-10 is in fixed size (800*600). Result metrics indicates total time consumed in each round by T(1) to T(10), and 4 additional metrics M(1) to M(4) which each indicates average time consumption per image in previous four groups of rounds.