Add a MRU cache for ImageCacheKey::GetSpecialCaseDocumentToken().
Categories
(Core :: Graphics: ImageLib, enhancement, P3)
Tracking
()
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
Details
Bug 1516540 shows how expensive this function has gotten now due to the
anti-tracking code. While we improve the anti-tracking backend, there
will be an upper bound to how much faster things can get since we will
be doing strictly more work.
Looking at the usage pattern of this function when browsing some common
websites shows that it could benefit a lot from a simple MRU cache by
saving a lot of repeated computation. This patch adds this cache.
Assignee | ||
Comment 1•6 years ago
|
||
I attempted to add an MRU cache for ImageCacheKey::GetSpecialCaseDocumentToken(), both with the default set of 31 and also with a size of 509 entries, and measured the results on the raptor tests which originally saw the regressions. Here are the results respectively: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=b9723fb2db983b1a164838faaf5bdc4162d24e95&newProject=try&newRevision=068403e709847bb843efbd3d6a9b630535bfbd19&framework=10 https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=b9723fb2db983b1a164838faaf5bdc4162d24e95&newProject=try&newRevision=3006a5942d122a29734e2fd3bdc3a0c6ec1bb444&framework=10. The larger cache seems to perform a bit better but neither of the patches meaningfully improves the workload, so I will sit on them for now while trying other approaches.
Updated•6 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
I ended up not needing to do this!
Description
•