Find out how much glyph cache between content processes not being shared is affecting talos numbers

RESOLVED FIXED

Status

()

Core
DOM: Content Processes
RESOLVED FIXED
4 months ago
4 months ago

People

(Reporter: mconley, Unassigned)

Tracking

50 Branch
Points:
---

Firefox Tracking Flags

(firefox53 unaffected)

Details

(Reporter)

Description

4 months ago
I don't believe the glyph cache is shared between content processes.

I'm not sure how easy it would be to have shared memory between content processes that could act as the cache.

Regardless, I _suspect_ this lack of caching is impacting the tps test for e10s-multi (see bug 1317312 comment 15). Not 100% sure, but that's what I'm starting to think based on a reading of the profiles in that comment.
(Reporter)

Comment 1

4 months ago
Hey jrmuizel,

You had a suggestion on how we could do some manual counting of certain function calls to prove that the lack of glyph cache is impacting us here. Can you remind me what that suggestion was, exactly?
Flags: needinfo?(jmuizelaar)
If you count the global number of calls to SkScalerContext_Mac::generateImage that should give you something to start with.
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 3

4 months ago
I added a printf statement here:

http://searchfox.org/mozilla-central/rev/f680e72cc6579f90b992b63ca14d923d2afea612/gfx/skia/skia/src/ports/SkFontHost_mac.cpp#1290

Did a single tps run, dumped the output to two logs - single-process.log for a single content process, and double-process.log for 2 content processes.

MacBook-Pro-104:mozilla-central mikeconley$ grep "mconley: SkScalerContext_Mac::generateImage" single-process.log | wc -l
   27718
MacBook-Pro-104:mozilla-central mikeconley$ grep "mconley: SkScalerContext_Mac::generateImage" double-process.log | wc -l
   30472

So it looks like we're definitely calling it more for 2 content processes.

Is that enough to draw a meaningful conclusion from?
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 4

4 months ago
I just talked to jrmuizel. The conclusion we can draw from comment 3 is:

There are some glyphs that are not being shared between the two content processes, and so need to be generated, which is taking time. In single-process, and single-content-process, the glyph cache is shared, so we can save some time.

Two things shake out from this:

1) gabor is going to modify tps so that it does a single pass through of all of the tabs before going through a second time and doing measurement. This is okay because tps is about switching to and painting loaded background tabs - not switching to tabs that we've never seen before.

2) Apparently, WebRender will give us a shared glyph cache, so that's nice.
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 5

4 months ago
We're done here.
Status: NEW → RESOLVED
Last Resolved: 4 months ago
status-firefox53: --- → unaffected
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.