search

cloudant / sync-android

A JSON-based document datastore for Android applications
Apache License 2.0
267 stars 90 forks source link

Speed comparison IOS and Android #612

Closed Waleedasim closed 2 years ago

Waleedasim commented 4 years ago

Please read these guidelines before opening an issue.

Bug Description

Basically we are comparing the iOS lib and the Android lib when syncing a few thousand docs. And we noticed that the iOS library is always faster (Approximately 2x faster) then the Android library using the same network. Is there any limitations or differences between these 2 libraries (Like why syncing is always faster in ios)? can we do something to make it faster in android just like ios? if not then, it could be a hardware issue (e.g. iPhones have a generally faster wifi chip?) or you can provide some details to sync data faster using this lib (just like ios)?

1. Steps to reproduce and the simplest code sample possible to demonstrate the issue

Slow snycing

2. What you expected to happen

fast syncing just like ios

3. What actually happened

slow Syncing

Environment details

com.cloudant:cloudant-sync-datastore-android:2.4.1

emlaver commented 4 years ago

Hello @Waleedasim, I'd suggest testing and comparing the results of your iOS app using the Xcode iOS simulator and your Android app using an emulator on the same machine.

trx222 commented 3 years ago

We see more differences between the two OS and libraries - and I think this is normal. But the performance is a big problem for us. Our application syncs database from own server running actual CouchDB version and the android version needs more and more time to start - if the changes in the server database becomes more. Our iOS app syncs very fast.

And as additional problem we see, that the sync blocks also reading and querying from the database while syncing so we can not sync in the background and let user use the app with existing data. Maybe anybody has a workaround for this.

ricellis commented 3 years ago

the android version needs more and more time to start - if the changes in the server database becomes more

Can you clarify please if you are talking about an initial replication to a new/empty device or an incremental replication from an existing checkpoint?

trx222 commented 3 years ago

For the initial replication I think it is ok, it takes the time and we display a splash screen ... but for the next replications, yes with existing data, the database is blocked and thatswhy our complete application blocks until the replication is finished and the querys getting the results ...

ricellis commented 3 years ago

Is there any limitations or differences between these 2 libraries (Like why syncing is always faster in ios)?

Yes, the libraries are completely different, one is written in Java for Android and one is written in Obj-C for iOS. The dependencies for interacting with the underlying SQLite database are also completely different.

Besides that iOS has 2 additional replication optimizations not present in sync-android:

  1. Only on an initial pull fetch all the winning revisions from _all_docs on the remote before commencing with the standard replication procedure. This is why I was asking if the replications were new or from existing checkpoints.
  2. Rewind to the last common seq rather than to 0 in the case that the local/remote replication checkpoints don't match (see #296).

can we do something to make it faster in android just like ios?

We could consider adding those optimizations, but I'd be surprised if it made a significant difference, they cover only edge cases. In the absence of any details about the replication or logs of a slow replication it is impossible to say whether they'd be beneficial.

if not then, it could be a hardware issue (e.g. iPhones have a generally faster wifi chip?)

Yes, there are lots of different hardware factors in play. I'd be particularly wary of storage speeds, AFAIK no iOS devices use e.g. SD cards to provide storage, but this is frequently seen on Android devices and can be subject to huge variation, both in the capabilities of the device and the speed of the inserted storage medium.

or you can provide some details to sync data faster using this lib (just like ios)?

the sync blocks also reading and querying from the database while syncing

All operations with the database are sent to a queue - a large pull replication requiring many writes to the local datastore will put a lot of work in that queue that other reads and queries might get queued behind, particularly if your storage IO is slow.

I'd also recommend double-checking that sync is actually what you need - I wrote up the core reasons to use sync in an issue in the iOS lib - if you don't have those requirements there are faster options than replication.