New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 641138 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 641135
Owner: ----
Closed: Sep 27
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 641135



Sign in to add a comment

createChildFrame is very slow

Project Member Reported by esprehn@chromium.org, Aug 25 2016

Issue description

Version: 52.0.2743.98
OS: Android N (Nexus 5X)

createChildFrame appears to do:

1. A sync IPC which takes anywhere from 1-3ms.
2. RenderFrameImpl::didCommitProvisionalLoad which takes 10ms.
3. Spawn 2-3 tasks on the IO thread which each take 5ms.


 
createFrame-too-slow.png
47.7 KB View Download
createFrame-too-slow-2.png
55.9 KB View Download
Blockedon: 641135

Comment 2 by nasko@chromium.org, Aug 25 2016

The sync IPC is required in order to get a routing id assigned by the browser process. The content::RenderFrame needs to be created for the iframe with a valid routing id, so we can't do this async. What is interesting to me is that the createChildFrame is overlapping the didCommitProvisionalLoad. Did you add a frame with no source or something else?
The commit will depend on the network, but should be synchronous for about:blank.

Comment 3 by dcheng@chromium.org, Aug 25 2016

When we create the frame, we synchronously commit the initial empty document: that's where that's coming from. I guess there's some subsystems doing a bunch of work in that callback...
esprehn confirmed to me that the slow didCommitProvisionalLoads are coming from about:blanks.

I'm trying to repro now with some added probe points. There have been a bunch of places where we add crash keys to learn about failed CHECKS. I wonder if those are contributing to the slowness if the CHECK succeeds (an alternative would be to CHECK_NOTREACHED() after an if so we only add crash keys on a known failure).
I was able to repro the slowness (~6ms didCommit*) on Chrome stable 52.0.2743.98 but could *not* repro on Chrome Dev (54.0.2837.2) or TOT (@414688). This was on a Pixel C. These methods were taking < .5 ms. 

Unfortunately, this means that adding probe points doesn't really help. Does anyone know if there were optimizations in this area since M52?
Labels: Needs-Feedback
Labels: -Needs-Feedback
Pls don't use Needs-Feedback for anything other than flagging bugs that need additional reporter (user of chrome) input.

Comment 8 by tkent@chromium.org, Sep 2 2016

Status: Available (was: Untriaged)
Has anyone reprod the slowness with a build > M52?
Project Member

Comment 10 by sheriffbot@chromium.org, Sep 4 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 11 by tkent@chromium.org, Sep 22 2017

Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
Project Member

Comment 12 by sheriffbot@chromium.org, Sep 24

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Mergedinto: 641135
Status: Duplicate (was: Untriaged)

Sign in to add a comment