bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

IPDL::PLayerTransaction::RecvUpdateNoSwap takes too long with e10s during TPS talos runs

Assigned to



2 years ago
a year ago


(Reporter: Gabor Krizsanits (INACTIVE), Assigned: gw280)


(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags



(Whiteboard: [gfx-noted])



2 years ago
See Bug 1186585 Comment 16 

(Another weird thing is that the content process spends quite a lot of time in PuppetWidget paint (~26%) which I don't see anywhere in the non-e10s case. Could someone explain me briefly why is that the case?)


2 years ago
Blocks: 1186585
Whiteboard: [gfx-noted]
We've discussed this a bit offline. RecvUpdateNoSwap is higher but I don't think it's accounting for a score difference since RecvUpdateNoSwap is an async call and the compositor is on time.

I'd like to find time to go through the profiles with mconley and look at what is going on in the main thread some more since I think the answer is in these profiles.
I just had a look and we could get a big score improvements by cutting down the time spent in 'IPDL::PBrowser::SendGetInputCont'. Some sub tests are dominated by this cost.
Flags: needinfo?(bgirard)


2 years ago
Assignee: nobody → gwright
Blocks: 1063169
tracking-e10s: --- → +
Priority: -- → P1
I'd like to come back to this.

Here are two recent profiles from my OS X machine with APZ disabled:



I've zoomed into two regions which I think are illustrative. Notice how the last layer transaction before the test is completed (the final composite that presents the loaded web content). In the non-e10s case, this takes 2-3ms... in the e10s case, we're spending something like 18ms doing what appears to be a memmove down in mozilla::gl::UploadImageDataToTexture.

And until that layer transaction completes, we don't composite, and the test doesn't end. I have a reasonably high-degree of certainty that this is our bottleneck.

BenWa: I seem to recall us discussing this one a few weeks back, and you convinced me that it wasn't an issue in-person. I'm sorry to say that I've forgotten our discussion. Looking at these profiles, are you still certain we don't care about these long memmoves in the e10s case?
Flags: needinfo?(bgirard)
At least part of the problem here, according to gw280 / mstange / jrmuizel, is that we're page faulting due to new texture allocations on tab switch. This is because we've got unique TexturePools per client, or something along those lines.

I'm doing an experiment where we have a shared TexturePool to see how much that gains us.
We've looked at the profiles on person and from Comment 5 it sounds like you have a lead. ni-
Flags: needinfo?(bgirard)
You need to log in before you can comment on or make changes to this bug.