Closed Bug 1324033 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: DOM: Content Processes, defect)

50 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox53 --- unaffected

People

(Reporter: mconley, Unassigned)

References

Details

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.
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)
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)
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)
We're done here.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.