Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Creating many windows and tabs at startup locks up the browser for some seconds #14082

Closed
petemill opened this issue May 10, 2018 · 1 comment
Labels
initiative/perf perf priority/P4 Minor loss of function. Workaround usually present. release-notes/include stale

Comments

@petemill
Copy link
Member

After single-webview was implemented, starting up with multiple windows and many tabs no longer locks up the browser for multiple minutes. However, the experience is still not very smooth.

The windows, and all the tabs for those windows are created at the same time. This results in an extremely high number of state changes to be communicated from browser -> window, an extremely high number of actions to be dispatched in the browser and sent to the window to be dispatched, and a high number of frame changes which are sent from the window back to the browser (and then sent to the window again upon state diff as the frames are added to the app state too).

This results in a lockup for a few seconds whereby, whilst some events get through, the browser and the windows all spend most of their time diffing and patching state changes, and processing individual actions for each tab.

Some ways to get around this:

  • Pause updates to windows until all initial tabs have been created and reached a certain lifecycle point (tab-inserted-at?)
  • Batch actions via debounce, even if only during the initial window / tab creation phase (could keep track of how many tabs were requested to be created at window creation time and wait for them all to receive a certain event).
  • When diffing appState for window appState updates, ignore paths that the windows do not care about, such as tabs[].tab.frame
  • Pause processing of state diff, store actions, and tab events in renderer process until it is informed that all initial tab operations have completed.

Description

Steps to Reproduce

Most obvious, but happens with any number of tabs really:

  1. Start browser using a profile that has 3+ windows, each with ~150 tabs

Actual result:
Tabs take many seconds to show up in windows, window rendering is thrashy, window titles in app's window menu changes

Expected result:
Windows open, shortly and smoothly followed by a full set of tabs.

Reproduces how often:
100%

Brave Version

about:brave info:
0.22.703

Reproducible on current live release:
It's even worse on current release due to also rendering for and attaching a webview to each tab in each window.

@petemill petemill added this to the 0.22.x Release 3 (Beta channel) milestone May 10, 2018
@petemill petemill self-assigned this May 10, 2018
@petemill petemill changed the title Creating many windows and tabs at startup locks up the browser Creating many windows and tabs at startup locks up the browser for some seconds May 10, 2018
@bsclifton bsclifton modified the milestones: 0.22.x Release 3 (Beta channel), 0.22.x Release 4 (Beta channel) May 14, 2018
@bsclifton
Copy link
Member

Moving to 0.23.x after discussion with @petemill - let's discuss in triage tomorrow

@bsclifton bsclifton modified the milestones: 0.22.x Release 4 (Beta channel), 0.23.x (Developer Channel) May 21, 2018
@alexwykoff alexwykoff added the priority/P4 Minor loss of function. Workaround usually present. label May 22, 2018
@alexwykoff alexwykoff modified the milestones: 0.23.x (Developer Channel), 0.24.x (Nightly Channel) May 22, 2018
@alexwykoff alexwykoff modified the milestones: 0.24.x (Nightly Channel), Backlog (Prioritized) Jun 12, 2018
@bsclifton bsclifton added the stale label Sep 3, 2018
@bsclifton bsclifton removed this from the Backlog (Prioritized) milestone Sep 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
initiative/perf perf priority/P4 Minor loss of function. Workaround usually present. release-notes/include stale
Projects
None yet
Development

No branches or pull requests

4 participants