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)
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.
Reporter | ||
Comment 1•7 years 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)
Comment 2•7 years ago
|
||
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•7 years 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•7 years 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•7 years ago
|
||
We're done here.
You need to log in
before you can comment on or make changes to this bug.
Description
•