[dev 5811] Session restore: TST sidebar - 1m30sec to restore, Firefox tab bar - 5 seconds

[SXZ1]

Nightly 20-11-17, TST dev5811.
I decided to test how quickly TST restores sessions compared to built-in Firefox tab bar. STR:
Create new profile, install TST dev, close Nightly, copy sessionstore.jsonlz4 from the archive to the root of the profile folder overwriting existing file. Session containts 500 tabs but tree structure is simple: around 10 parent tabs with 490 child tabs, no stack in stack.
sessionstore.zip
Launch Nightly - Hamburger menu - Restore Previous Session

AR: Tabs in Firefox tab bar are restored and fully functional after 5 seconds, tabs and tree structures in TST sidebar are restored and functional after 1 minute 30 seconds.
I tried to benchmark TST2.2.9 as well (same STR), it is a bit faster - 1 minute 15 seconds.

[SXZ1]

Screenshot of restored session

[nh2]

I have this problem too. Around the same number of tabs, around 2 minutes start time (probably runinng on slightly oder hardware than yours, i5-2500).

[SXZ1]

Nope, I got i5 2300 (desktop), Asus PB75-V.

[nh2]

OK, mine is a laptop (i5-2520M), so that's probably still in line.

[dset0x]

Startup is not really an issue for me, perhaps because I use ~10 windows with ~20 tabs each (I slowly and painfully migrated my groups to windows now that Tab Groups are gone). There is a noticeable delay when creating / deleting tabs, so perhaps the issue lies there somewhere.

What's really slow is moving tabs from one window to another. The TST bar will turn dark gray and unresponsive for several seconds while that happens.

[BeatBurgener]

Same experience here with Tab Session Manager and TST. Using the native FF session restore is swift (and does not load all the content of all tab's). Using Tab Session Manager will take ages and load all the (inactive) tabs in full ... not sure if this is a TST issue though ... despite the fact that TSM has an integration with TST ...
Just FYI ...

And many thanks for the excellent add on (plus porting it to FF 57!)

[piroor]

After performance profiling, I've noticed that needless reflowing is the largest bottleneck. So I've tried to remove it via recent commits.

[SXZ1]

I've just benched TST2.2.11.5896

Firefox tab bar - 5 seconds
TST2.2.11.5896 - 47 seconds
TST2.2.2.9 - 1 minute 15 seconds
TST2.2.11.5811 - 1 minute 30 seconds

Great job, @piroor ! \o/

[piroor]

Thank you for confirmation! It is still quite slower than Firefox's session restoration, so I hope to do more optimization, but currently I have no more idea how to do that...

[wdnz]

How can I install this version? My config shows version 2.3.0 from today, 30. November (downloaded from AMO) - or is the change already integrated?

[piroor]

Yes, it is a part of this update.

[piroor]

I've introduced a new cache-based optimization and it is activated by default on the latest development build. It seems to work correctly for me, but I still need more dogfooding because it is very large change. Could anyone help me?

If you see completely broken tree, please deactivate the cache system: TST configurations => debug mode => uncheck "useCachedTree", then the optimization is disabled.

[SXZ1]

I installed the latest dev build and restored my saved session with ~500 tabs and lots of trees at least 20 times without any problems. Sessions are also restored faster, it looks like new caching system works perfectly. Thank you very much, @piroor !

I'll bench new dev version later.

[SXZ1]

I've benched 2.3.0.6023

Firefox tab bar - 5 seconds
TST2.2.11.5896 - 47 seconds
TST2.3.0.6023 - 55 seconds
TST2.2.2.9 - 1 minute 15 seconds
TST2.2.11.5811 - 1 minute 30 seconds

[piroor]

Due to some restrictions, the cache is not used if there is any extra tab or missing tab. And TST can use cache only for the background page on the "Restore Previous Session" case. If you choose Firefox's preferences => "General" => "When Firefox(Nightly) starts" => "Show your windows and tabs from last time", TST will use cache both for the background page and the sidebar.

[piroor]

And I've found a fatal bug around window restoration (It has been fixed by recent commits). Before retrying you should update the development build...

[SXZ1]

Benched 6027. "When Nightly starts" set to "Show your home page", session restored using hanburger menu - restore previous session.
Firefox tab bar - 5 seconds
TST2.2.11.5896 - 47 seconds
TST2.3.0.6027 - 52 seconds
TST2.3.0.6023 - 55 seconds
TST2.2.2.9 - 1 minute 15 seconds
TST2.2.11.5811 - 1 minute 30 seconds

[piroor]

By recent changes, now the cache is applied for "Restore Previous Session" case.

[piroor]

Hmm, on my PC the large session couldn't be restored with cache...

[SXZ1]

Hmm, on my PC the large session couldn't be restored with cache...

Same thing on my config with 6035. I didn't notice any improvement in session restore speed compared to previous builds,

[SXZ1]

I am talking about the case when "When Nightly starts" is set to "Show home page"

[piroor]

After some changes, now 500+ tabs are restored in 30sec for me. Most part of the delay is definitely required to wait until tab's session data become readable, so I think now we are very near the barrier impossible to be broken.

[SXZ1]

Tried to bench 2.3.6043 with 500 tabs session from the first post, New profile, "When Nightly starts" set to "Show home page".
1st try - 1m
2nd try - 45sec
3rd try - 21sec
I guess that's because it takes some time to build the cache.

[piroor]

By recent changes, now the cache is used for all of following cases:

• Firefox's preferences => "General" => "When Firefox(Nightly) starts" => "Show your windows and tabs from last time"
• Firefox's preferences => "General" => "When Firefox(Nightly) starts" => "Show your home page" / "Show a blank page" + "Restore Previous Session"
  • Without extra tabs (no tab opened before "Restore Previous Session" is done)
  • With extra tabs (some tabs are opened before "Restore Previous Session" is done)
• "History" => "Recently Closed Windows"

[reikred]

I have some more data for this issue report (1596), or at least I think it is the same issue. After finding this report I debated whether I should just tack my observations on here, or open a new one. Since this report is still marked as "only" partially fixed, I figured I may tack on my observations here, as follows:

Test case: firefox 58.0, and a particular test profile with 1237 tabs. The test measures how long it takes to start the browser and load a set of tabs, up to the point where the browser is responsive, meaning that one can view tabs and switch between windows and tabs and have them rendered. Basically "responsive" means that the browser is navigable and viewable. Let us call this delay the start-to-responsive-state latency or STRS latency.

Test results:

TST=enabled tabs=1237 CPU.start-to-responsive-state=13min42sec
TST=disabled tabs=1237 CPU.start-to-responsive-state=35sec

It is observed that TST=enabled has a massive effect on the STRS latency, BUT it is also observed by trial and experiment that the number of tabs to be loaded is highly significant. In fact if there is only 10 or 20 or even 100 tabs to be loaded, the latency is not even 1 minute.

It looks to me like there is roughly a cubic O(n^3) latency effect as a function of the number of tabs, given the observations for a 500 tab case reported by contributor SXZ1 above. I see he was running on a i5-2300 while mine is an i7-4770.

CALCULATE: (1227/500)**3
= 14.778272664

With 14min versus about 1min, if CPUs were equal, this data would suport the O(n^3) hypothesis, but since my CPU is faster it seems likely that the latency is worse than O(n^3).

By the way, with respect to the STRS latency dependency on the number of tabs, there does not appear to be much difference between firefox-56 with TST-0.19.x and firefox-57/58 with TST-2.x. (2.4.20 in my case)

I hope my data point can inspire some further investigations and improvements.

[piroor]

I close this because outdated.