I really didn’t understand the reason why a computation scheduler was used in this project except for that it was used for the throttle operator.
Is this common practice vs just using the IO scheduler? I tried to do some research but came up with just good explanations of the types and not whether one should use a particular scheduler or not.
Just wondering.
Thank you
@arrmixer Great question!
The answer to your question kind of has two parts:
- Why pass a scheduler in at all? If you look through the RxJava docs, you’ll see that there’s a version of
throttleFirst
that doesn’t require a Scheduler
at all. We’re using the overload that accepts a Sheduler
instance so we’d be able to easily test this rx flow moving forward. Since throttleFirst
deals with time, it’s extremely helpful to be able to pass in a TestScheduler
to manually advance time in unit tests. That’s the impetus for actually passing the scheduler in - to be able to inject a different scheduler of our choosing when writing unit tests.
- Ok, but why use the
computation
scheduler instead of the IO
scheduler? If you dig into that version of throttleFirst
that doesn’t accept a Scheduler
you’ll see that it’s using the computation
scheduler under the hood. Typically you want to reserve usage of the IO Scheduler
to IO operations - so things like fetching something from a network or reading some values from a database. The RxJava Scheduler
s typically operate with fixed size thread pools, so if you’re using the IO
Scheduler
for operations like throttleFirst
that just block for some amount of time, you could actually end up in a scenario where you run out of Thread
objects in the IO
thread pool under the hood and your network/database calls end up having to wait for those timing operations to time out. The computation Scheduler
, on the other hand, is really tailored towards these types of time or event loop or heavy computation based tasks.
I hope that answers your question!
Hey @alexsullivan! thanks for your response and great explanation. Sorry for the late reply. I didn’t notice that throttleFirst uses the comp scheduler under the hood.
So my follow up question, is it considered a better approach to use the comp scheduler for UI events like click events or text/focus changes on view components?
I always used IO schedulers in the past but never chained it with the throttle operator.
I know that If I used the throttle operator with a RxUI observable I need to use the Comp scheduler. But if I don’t use the throttle operator, should I still use the comp scheduler instead?
Angel
@arrmixer Good follow up question!
I typically only use the computation
scheduler in two scenarios:
- The operator I’m using deals with time. So, operators like
throttle
, debounce
, window
and so on - really anything that does something after a set amount of time. Again, I use the computation
scheduler instead of the IO
scheduler so as not to block the IO thread pool for network/database calls.
- I’m performing a lot of really heavy manual computation (so things like vector calculation, matrix manipulation, image processing and so on) which is very rare, at least for me.
So it actually isn’t really important whether you’re dealing with UI events - what’s more important is whether the operator operates on time or not.
Does that clear things up?
1 Like