Massive slowdown in session restore / chrome responsiveness with dom.ipc.processCount = -1
Categories
(Firefox :: Session Restore, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox69 | --- | affected |
People
(Reporter: yoasif, Unassigned)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Not the smartest thing in the world, but I have been running Firefox with dom.ipc.processCount = -1 to stress test this feature.
I found that bug 1543684 regressed session restore immensely, making it impossible to get suggestions from the awesomebar, or even type into it for minutes after launch.
This is clearly an edge case, but dom.ipc.processCount = -1 worked fine prior to this change, and perhaps there is something that can be done to improve this.
Changing dom.ipc.processCount = 30 works fine as well.
12:54.69 INFO: No more inbound revisions, bisection finished.
12:54.69 INFO: Last good revision: 65de6e306adb3257187dcb00fab74b0333765ab3
12:54.69 INFO: First bad revision: ce950f1fe559c61010ac30386a607fe29bca82b6
12:54.69 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=65de6e306adb3257187dcb00fab74b0333765ab3&tochange=ce950f1fe559c61010ac30386a607fe29bca82b6
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
I appreciate that you filed this bug :)
Bug 1543684 seems highly unlikely to have regressed sessionstore performance to this degree compared to how it was before that patch, since the code that I changed is only run during browser startup.
Please feel free to re-open this bug if you can find a better candidate for this regression.
Reporter | ||
Comment 2•5 years ago
|
||
Mike, you were right -- I just tried reproducing it in today's build and I can't reproduce it anymore. Should have taken a backup of the profile.
Sorry about the bad bug.
Updated•5 years ago
|
Description
•