-
Notifications
You must be signed in to change notification settings - Fork 875
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Severe performance regression in onSnapshot
listeners in Cloud Firestore
#2620
Labels
Comments
Thank you very much for reporting this and the very detailed reproduction! Really appreciate it! It turns out from #2624 should fix this regression. Again, thanks for reporting this! |
Fix is merged. This should be fixed in next release. |
I can confirm that Firebase 7.9.1 fixes this issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
[REQUIRED] Describe your environment
[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 useswindow.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.
The text was updated successfully, but these errors were encountered: