1388758 - Restoring sessions with multiple windows is very slow

Status: NEW

(Firefox :: Session Restore, defect, P3)

Description

[Florian Quèze [:florian]]

See this profile where on a very fast macbook; restoring a session with 15 windows (14 of which contained only 1 tab with about:home) took more than 5s: https://perfht.ml/2wIrz5U

Looking at the JS code doesn't show me obvious problems. There's certainly stuff we could optimize, but it would be small wins.

Looking at the platform stuff however, there seem to be a lot of time spent with the main thread blocked on sync IPC. PLayerTransaction::Msg_GetTextureFactoryIdentifier and PCompositorBridge::Msg_FlushRendering specifically seem to account for a lot of the time.

Comment 1

[Worcester12345]

Please add "perf" key word. Thank you.

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

Florian, what do you want to do with this bug? Should we move it to Core and ask IPC experts to take a look, or do you want to get a new profile and see where things stand now?

Comment 3

[Florian Quèze [:florian]]

(In reply to Panos Astithas [:past] (please ni?) from comment #2)
> Florian, what do you want to do with this bug? Should we move it to Core and
> ask IPC experts to take a look, or do you want to get a new profile and see
> where things stand now?

I think the profile here is likely obsolete at this point. Restoring sessions could do with performance improvements, so it may be useful to reprofile someday.

Comment 4

[:Gijs (out for now; he/him)]

A new profile with 12 non-empty windows on a very fast Windows machine shows some significant JS/frontend involvement, but still manages to show the first sign of UI within 1s. It's difficult to disentangle cases where JS e.g. inserts a browser element and that leads to a flurry of core/ipc activity, so I'm not sure that this really shows a big gaping thing we should go and pursue.

I also think that the number of people with large sessions is such that realistically this should probably be low perf impact.