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

Issue 637140 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Investigate why OOP Json parsing had such a huge impact on Chrome startup

Project Member Reported by asvitk...@chromium.org, Aug 11 2016

Issue description

Investigate why OOP Json parsing had such a huge impact on Chrome startup.

This is one of the action items from go/m51-startup-regression-postmortem

The original problem was fixed by this CL: https://codereview.chromium.org/2140093002 - which switched OOP Json parsing to in-process.

In UMA metrics, we saw something like a 1s difference in median time in the Startup.FirstWebContents.MainNavigationStart metric.

We want to find out why it's such a huge difference, as suggested by kgr@:

"I think there should be an action item to determine why performing the parsing OOP is so much more expensive than performing it in-process. Chrome's architecture relies heavily on process separation and IPC, so lessons here could be broadly applicable."

Bruce, assigning to you since you volunteered to take a look.

One note of warning is when were trying to test things in the lab, we had a hard time reproducing the regression (before we knew the cause, just comparing M50 to M51). Hopefully, you'll have better luck!
 
The original bug is 607946. Some of the detailed discussions of the root cause are in these comments:

https://bugs.chromium.org/p/chromium/issues/detail?id=607946#c132

In particular, this CL introduced the problematic code:

https://codereview.chromium.org/1853753003

This investigation was described as an investigation to find out why OOP json parsing had such a huge impact (compared to in-process json parsing) but it sounds like the costs were from:
- Creating an extra utility process
- Parsing up to 6 files doing startup
- And doing this out-of-process

The fix seemed more focused on delaying the parsing rather than doing it in-process.

I'm not seeing the indication that OOP parsing was costing more than in-process parsing. Was that effect isolated somewhere?

We did an experiment that tried to isolate which was the cause, and the results are reported here:

https://bugs.chromium.org/p/chromium/issues/detail?id=607946#c179

In particular, group NoOOPParsingButNoDelay is the one which turned off OOP parsing but without adding a "post startup" delay. From that comment, that group saw all the improvement.

Comment 3 by gab@chromium.org, Sep 8 2016

Bruce, do you have all you need to proceed with this investigation? If not, please let me know and I'm happy to help you set up a build with the issue.

Recap from email discussion:

Reverting (in order) 68cd24d76191cf57b2038c99e4c988b1d4bb5029, af4e289461794790203de6d050198b7e8e7ad5d1, 6cc7584e55ab69b8a3454f1054fcf982f4a2584a should get you back to the previous state on trunk.

You probably also need to revert a414e99dbf38480dc4ac6e69368c2b13b0b6a0f0 for it to run without crashing (mostly unrelated but that component happened to be the last user of a deprecated API which that revert brings back).
I think I have the information I need - now I just need the time :-)

Comment 5 by gab@chromium.org, Oct 3 2016

@bruce: any chance to get around to this? I suspect repro will become harder and harder overtime with codebase diverging. Let me know if you'd like me to attempt to find someone to get their hands dirty here :-)
No chance so far, or in the next few weeks, but I'm not worried. I can always sync back to the problematic state. If somebody else wants to grab it I wouldn't object, and could offer assistance, but if there's no rush then there's no harm leaving it with my name attached.

Sign in to add a comment