Use of Computation Scheduler in Last Chapter

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:

  1. 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.
  2. 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 Schedulers 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:

  1. 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.
  2. 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

@alexsullivan

yes! thank you! :pray: :muscle: