Hello! After upgrading from 16.19.1 to 17.1.0, we observed a concurrency-related performance regression.
Scenario
The app renders an effectively infinite list of rows.
Each row starts its own query subscription when it becomes visible.
In parallel, a shared worker computes and inserts records into the same collection those rows query.
Expected behavior (as in 16.19.1)
Subscriptions consistently emit results in about ~100ms, regardless of concurrent inserts.
Actual behavior (in 17.1.0)
While inserts are running, many subscriptions are significantly delayed.
When no inserts are happening, subscription performance remains the same as before.
I've also managed to create an example reflecting this scenario. Writes happen in the same thread as queries but it still indicates a regression:
rxdb-browser-subscription-contention-benchmark.html
Hello! After upgrading from 16.19.1 to 17.1.0, we observed a concurrency-related performance regression.
Scenario
The app renders an effectively infinite list of rows.
Each row starts its own query subscription when it becomes visible.
In parallel, a shared worker computes and inserts records into the same collection those rows query.
Expected behavior (as in 16.19.1)
Subscriptions consistently emit results in about ~100ms, regardless of concurrent inserts.
Actual behavior (in 17.1.0)
While inserts are running, many subscriptions are significantly delayed.
When no inserts are happening, subscription performance remains the same as before.
I've also managed to create an example reflecting this scenario. Writes happen in the same thread as queries but it still indicates a regression:
rxdb-browser-subscription-contention-benchmark.html