Here's a start-up profile that dietrich took:

https://perfht.ml/2VKT0cv

Checking to see if a tab is in Reader Mode seems particularly expensive. Apparently, we're doing this by accessing the URI on the tab, and checking to see if it starts with about:reader. Perhaps this is something we could add to the tab state in SessionStore instead.

Another thing that seems strange is that we appear to have some compartment crossing overhead here... why are we crossing compartments? Why is accessing the tabbrowser.js stuff from the ext-tabs.js stuff crossing any kind of compartment boundary?

We found this during Episode 33 of The Joy of Profiling, which is pending upload to Air Mozilla.

Adding the [fxperf] tag because this could impact start-up for users that have large sessions, and WebExtensions that query tabs.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #0)

Here's a start-up profile that dietrich took:

https://perfht.ml/2VKT0cv

Checking to see if a tab is in Reader Mode seems particularly expensive. Apparently, we're doing this by accessing the URI on the tab, and checking to see if it starts with about:reader. Perhaps this is something we could add to the tab state in SessionStore instead.

Another thing that seems strange is that we appear to have some compartment crossing overhead here... why are we crossing compartments? Why is accessing the tabbrowser.js stuff from the ext-tabs.js stuff crossing any kind of compartment boundary?

Because ext-tabs.js lives in a Sandbox (for stupid reasons involving interns) and tabbrowser.js lives in a browser window. Until a few days ago, those had to be in separate compartments.

The biggest chunks of this are cross-compartment overhead and creating the URI objects for lazy tabs. The latter is going to happen anyway, and the former goes away with bug 1514210, so I'm inclined to close this.