Investigate why OOP Json parsing had such a huge impact on Chrome startup |
|
Issue descriptionInvestigate 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!
,
Aug 12 2016
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.
,
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).
,
Sep 9 2016
I think I have the information I need - now I just need the time :-)
,
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 :-)
,
Oct 11 2016
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 |
|
Comment 1 by brucedaw...@chromium.org
, Aug 12 2016