We set three tiers that we’ll use to theme and prioritize sessionstore component work: Tier 1: Reliability Tier 2: Performance Tier 3: Feature development and maintenance Performance is something we’re keen to look at. We’ve identified the following sub-themes: 1. Perceived performance. 1.1 We’re restoring windows and tabs in a loop that yields and moves to the next item in a serial fashion. Ideally, this would happen in parallel. 1.2 We’re not keeping the last active window and the last active tab in that window in front of the user whilst restoring. Ideally, other windows and tabs would open in the background, out of sight. 1.3 Various animations are active whilst restoring windows and tabs, like window resizing animation, tab-open animation, tab-overflow animation(s), etc. Ideally, these would be disabled during restore. 2. Measure before work 2.1 Create an ‘arewefastyet.com’-style dashboard for sessionstore REstore, including telemetry and Talos data. 2.2 Currently we have one Talos test that opens one window and over a hundred tabs. Add a test with multiple windows and take that as the baseline. 2.3 We are currently writing an uncompressed JSON blob to disk. We should consider using lz4 compression, which is fast and part of OS.File already. 2.3.1 Smaller writes = less time spent on flush 2.3.2 Less flush means smaller window of data corruption (crash during flush) 2.3.3 Faster reads of smaller files from disk should improve startup restore performance (measurable) 2.3.4 Fewer I/O ops should lessen strain on profile dirs located on network drives 2.4 Firefox Flow - there’s an opportunity to be part of this initiative by including sessionstore work. Bugs which have 'performance' as its main theme will be marked blocking this bug.
Sir , I want to work on this issue.