Last time, I wrote about why you should stop using RxLifecycle. This week, I have an earth-shattering Rx revelation to share!
Forgive my excitement if you already knew this, but did you know that the zip() function does not run commands in parallel?
This article does an amazing job of explaining what is happening and how to solve it:
https://medium.com/rxjava-tidbits/rxjava-tidbits-2-parallelism-with-observable-zip-6ef3c5a61a22
In the app I’m working on, we were using a timeout() to emit an error if the Observable (in this case, coming from a Bluetooth-connected device) did not respond. However, we found that sometimes these commands were timing out unexpectedly. We thought this might be because we were zipping so many things together (10), and BLE is slow that it was exceeding our timeout. However, writing a unit test confirmed that while adding these additional subscribeOn calls helps overall performance (since commands are run in parallel), it doesn’t help with the timeout issue — because the timeout was set for each individual command, and the timer does not begin until the observable is subscribed to. So, in our case, we eventually discovered one command that really was timing out, unrelated to it being zipped with so many other commands.
This was a big eye-opener for me, and I have since audited our app for other large zip() statements that can be parallelized to improve performance.
I hope you learned something helpful! Have you had other “aha!” moments with Rx? I’d love to hear about them in the comments! And, please follow me on Medium if you’re interested in being notified of future tidbits. I'll be on vacation next week, but will be back later on in September with more tidbits!
This tidbit was discovered on August 26, 2020.
Top comments (0)