Glandium radar'd a profile of their startup of a profile with about 2000 tabs on #firefox on slack.

We end up spending a full second on the repeated querySelector calls for tab:hover, which on startup is probably not needed anyway. The next biggest hitter is checking _visibleTabs, which requires getting all tabs and filtering on the hidden attribute, as well as checking multiselected - all from _setPositionalAttributes.

Batch-inserting them would at least avoid calling _setPositionalAttributes more than once per window. The main thing I'm unsure about at a glance is whether we would want to create a dedicated method or figure out a param we can pass (or are already passing) to addTab to allow us to skip expensive bits and just do them once at the end... I suspect a dedicated thing to bulk-insert tabs would be best, but I'm not sure how messy it would be and/or how much code we'd be duplicating / maintenance hassle we'd create. Fortunately, the add-on work is probably more manageable now than when I filed this bug given the demise of chrome/xul/js/xpcom add-ons.

There are also lots of insertBefore calls. I wonder if we could insert the tabs to a document fragment so that all tabs are inserted at once into the document.

I loaded 400 tabs and restored them.
With patch: https://perfht.ml/2Rk8VyG
Without patch: https://perfht.ml/34QnbTE

There is a 1,301 ms improvement within ssi_restoreWindow, but this is reduced depending on the number of tabs we load.

(In reply to Emma Malysz from comment #11)

I loaded 400 tabs and restored them.
With patch: https://perfht.ml/2Rk8VyG
Without patch: https://perfht.ml/34QnbTE

There is a 1,301 ms improvement within ssi_restoreWindow, but this is reduced depending on the number of tabs we load.

These profiles both show a lot of time spent in Servo_TraverseSubtree (triggered from nsCSSFrameConstructor::ContentAppended) for every document fragment we insert into the document. We are doing sequential styling there, but the refresh driver ticks triggers parallel styling.
I asked emilio about it, and he said it's because there's a hack for XUL (actually I think this was to support XBL binding attachment) at https://searchfox.org/mozilla-central/rev/ea63a0888d406fae720cf24f4727d87569a8cab5/layout/base/nsCSSFrameConstructor.cpp#6412

He thinks we should see a pretty massive difference if we remove that hack. This is covered by bug 1584935.

https://hg.mozilla.org/mozilla-central/rev/ea61d93b2616