[REQUIRED] Describe your environment

• Operating System version: Windows 10 Version 1909
• Browser version: Google Chrome Version 80.0.3987.87 (Official Build) (64-bit)
• Firebase SDK version: 7.8.1, since 7.3.0
• Firebase Product: firestore (auth, database, storage, etc)

[REQUIRED] Describe the problem

SDK 7.3.0 introduced a severe performance regression in the Firestore onSnapshot listener mechanism.

We listen to up to 3000 writes per second written in batches of 50 per transaction. As of SDK 7.2.3, each round of 3000 writes takes approximately 1 second, but often blocks the event loop for up to the entire second. Starting with SDK 7.3.0, this same amount of writes takes upwards of 30 seconds, also often blocking the event loop for the entirety of the duration. Our users were complaining that their browsers were recommending that they close their tabs due to unresponsiveness.

I have prepared a sample project to reproduce this problem. Here are some relevant screenshots with simple measurements. In the report columns, "RAF" is used as a placeholder for requestAnimationFrame. The sample project uses window.requestAnimationFrame to determine the severity of event loop blocking.

SDK 7.2.3

SDK 7.3.0

SDK 7.8.0

SDK 7.8.1

It seems that there have been improvements since SDK 7.3.0, but stalling the event loop for 25 seconds as of SDK 7.8.1 is still unacceptable.

As is noted in the sample project, it is not easily possible to determine the duration of the first invocation of onSnapshot for an update session. Because of this, all reported times are optimistic: the actual duration of an update session is always worse than is written to the page.

Steps to reproduce:

See https://github.com/djsweet/firestore-looplock-bug-report for an environment which reproduces this problem.