Closed Bug 1242912 Opened 4 years ago Closed 3 months ago
Allow batch creating tabs for session restore
47 bytes, text/x-phabricator-request
|Details | Review|
Looking at a profile for this stuff, it seems like creating the tabs and their linked browsers in one go in a documentfragment, and only appending them when we need their XBL stuff to be bound, would help a lot with bug 1135214 (admittedly an extreme case!) and startup perf when restoring tabs generally. Related to bug 906076, but not the same. That also doesn't look like it'll be ready to land for a while, and would also require a lot of add-on work. This is a perf improvement specifically for startup itself, and would help without requiring anything else from add-ons.
It's actually the opposite of bug 906076, right?
(In reply to David Rajchenbach-Teller [:Yoric] (please use "needinfo") from comment #1) > It's actually the opposite of bug 906076, right? No? bug 906076 does nothing about how we create <tab> elements themselves, it only deals with the linked browser for each tab. Adding 1500 tabs one at a time causes a lot of churn in how we do a lot of things in addTab() in the tabbrowser that are optimized for adding a new tab using the new tab button (like setting positional / selected attributes). Adding all the tabs in one go and only updating those attributes once would be faster. Similarly, instead of adding the linked browsers one at a time as we do now, we could add them all in one go. Of course, bug 906076 might obviate the need to do that at all if we stop creating linked browsers as soon as we create a <tab>. Even so, judging by the profile from the bug this blocks, just optimizing how we create <tab>s should help.
Is this a duplicate of bug 900803? Or maybe the other way?
(In reply to Florian Quèze [:florian] from comment #3) > Is this a duplicate of bug 900803? Or maybe the other way? Yes, one way or another. I don't feel strongly about which way to dupe. I imagine the relative perf gain here is now more significant than when the patches for bug 900803 were written, given the existence of lazy browsers - spending less time creating browsers means more of the time we do spend is spent on the tabs.
I assume the patch in bug 900803 has suffered severe bitrot at this point, so let's keep the bug with the fewest comments.
Assignee: nobody → emalysz
Whiteboard: [fxperf] → [fxperf:p2]
Attachment #9109743 - Attachment description: Bug 1242912, updated batch insert method → Bug 1242912, batch insert tabs during a session restore instead of adding tabs individually.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/ea61d93b2616 batch insert tabs during a session restore instead of adding tabs individually. r=Gijs
You need to log in before you can comment on or make changes to this bug.