Last Comment Bug 1324033 - Find out how much glyph cache between content processes not being shared is affecting talos numbers
: Find out how much glyph cache between content processes not being shared is a...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Content Processes (show other bugs)
: 50 Branch
: Unspecified Unspecified
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Bill McCloskey (:billm)
Mentors:
Depends on:
Blocks: 1317312
  Show dependency treegraph
 
Reported: 2016-12-16 09:30 PST by Mike Conley (:mconley)
Modified: 2016-12-20 12:06 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected


Attachments

Description User image Mike Conley (:mconley) 2016-12-16 09:30:32 PST
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.
Comment 1 User image Mike Conley (:mconley) 2016-12-16 09:31:28 PST
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?
Comment 2 User image Jeff Muizelaar [:jrmuizel] 2016-12-16 10:08:15 PST
If you count the global number of calls to SkScalerContext_Mac::generateImage that should give you something to start with.
Comment 3 User image Mike Conley (:mconley) 2016-12-16 22:41:46 PST
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?
Comment 4 User image Mike Conley (:mconley) 2016-12-20 12:05:53 PST
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.
Comment 5 User image Mike Conley (:mconley) 2016-12-20 12:06:23 PST
We're done here.

Note You need to log in before you can comment on or make changes to this bug.