Hi,
My android app gets very unresponsive during the initial pull replication (+/- 3000 docs, 100kb each).
When the app is open, at first I set up all the views(+/- 10 views).
Once the pull replication is started, the docs start arriving (and the views start being updated accordingly).
Is there any debouncing mechanism that avoids updating this indexi too often?
3000 docs at 100kb each is 300mb! Is that going to every device? Is any of it data that could be preloaded?
Hi @hod.greeley
Its a lot indeed.
There is a preloading that brings to the user basic usability at first run. (the first 30MB or so).
Most of the users don’t have such a large database.
However, the ones with heavy use, will produce around 50MB of data per month. After a while, if this user needs to resync all its data to a new phone or wants to share this data with some friend’s account, well, in this case the phones almost burn up 
To the core of the problem in hand, downloading the data isn’t that expensive (from computation point of view), however updating the views is, so there should be a way to mitigate this waste of computation.
View indexes are not updated automatically on insert the way SQL indexes are. They’re updated lazily when they’re queried. So apparently you are running a lot of queries on the views while the replicator is inserting documents. Try to query less often.
Also, look at your map functions to make sure they’re not doing more work than they need to. The map function can easily become a performance bottleneck.
Most of my queries are in fact livequeries that are coupled to adapters. I’ll try to do some debouncing there.
There is logic in LiveQuery to limit the rate at which it re-runs the query, but the details vary between platforms; I’m not sure how exactly it’s done in C#. You may want to pause the LiveQueries while the large-scale pull is running. Also make sure that a LiveQuery driving a GUI component is paused when that component isn’t visible.