{"action":"created","issue":{"url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4002","repository_url":"https://api.github.com/repos/ReactiveX/RxJava","labels_url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4002/labels{/name}","comments_url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4002/comments","events_url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4002/events","html_url":"https://github.com/ReactiveX/RxJava/issues/4002","id":159800246,"number":4002,"title":"Discussion: For Android, would it be reasonable to reuse a single scheduler for both io() and computation()?","user":{"login":"hzsweers","id":1361086,"avatar_url":"https://avatars.githubusercontent.com/u/1361086?v=3","gravatar_id":"","url":"https://api.github.com/users/hzsweers","html_url":"https://github.com/hzsweers","followers_url":"https://api.github.com/users/hzsweers/followers","following_url":"https://api.github.com/users/hzsweers/following{/other_user}","gists_url":"https://api.github.com/users/hzsweers/gists{/gist_id}","starred_url":"https://api.github.com/users/hzsweers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hzsweers/subscriptions","organizations_url":"https://api.github.com/users/hzsweers/orgs","repos_url":"https://api.github.com/users/hzsweers/repos","events_url":"https://api.github.com/users/hzsweers/events{/privacy}","received_events_url":"https://api.github.com/users/hzsweers/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-06-12T00:23:27Z","updated_at":"2016-06-12T00:52:41Z","closed_at":null,"body":"Posing this question here to see what the community thinks:\r\n\r\nCurrently, the default implementations for `io()` and `computation()` are very different but sound. A lot of developers end up replacing the `io()` scheduler with a bounded scheduler of their own that's less generous with allocating threads than the default, and I'm wondering actually if it'd make sense to just have a single generic \"background\" scheduler of sorts for use on Android that backs both. Considering it's a constrained environment and not powering a backend server, I'm interested to see if others have strong feelings or conventions around this.\r\n\r\nThe documentation/history behind `CachedThreadScheduler` and `EventLoopScheduler` are relatively scarce as well, so it's not totally obvious to me if there are obvious benefits to still having different implementations for them on a mobile environment."},"comment":{"url":"https://api.github.com/repos/ReactiveX/RxJava/issues/comments/225402858","html_url":"https://github.com/ReactiveX/RxJava/issues/4002#issuecomment-225402858","issue_url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4002","id":225402858,"user":{"login":"artem-zinnatullin","id":967132,"avatar_url":"https://avatars.githubusercontent.com/u/967132?v=3","gravatar_id":"","url":"https://api.github.com/users/artem-zinnatullin","html_url":"https://github.com/artem-zinnatullin","followers_url":"https://api.github.com/users/artem-zinnatullin/followers","following_url":"https://api.github.com/users/artem-zinnatullin/following{/other_user}","gists_url":"https://api.github.com/users/artem-zinnatullin/gists{/gist_id}","starred_url":"https://api.github.com/users/artem-zinnatullin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/artem-zinnatullin/subscriptions","organizations_url":"https://api.github.com/users/artem-zinnatullin/orgs","repos_url":"https://api.github.com/users/artem-zinnatullin/repos","events_url":"https://api.github.com/users/artem-zinnatullin/events{/privacy}","received_events_url":"https://api.github.com/users/artem-zinnatullin/received_events","type":"User","site_admin":false},"created_at":"2016-06-12T00:52:41Z","updated_at":"2016-06-12T00:52:41Z","body":"`io` is unbounded for a reason — IO stuff tends to block the thread it runs on, so I'd still keep `io` unbounded even on resource constrained system (Android).\r\n\r\n`computation` usually used for time-related operators and computations that do not involve any IO work and basically use only CPU and memory — I'd keep it as is at the moment with number of threads equal to number of CPU cores because it simply best you can do for computations.\r\n\r\n**Moreover**, I think with single, bounded generic scheduler you will actually lose in both performance and resource usage except memory. If app will do things slower (IO can block pretty much all threads in your bounded scheduler on slow internet connection) `->` user will have to wait longer `->` device will probably consume more battery because CPU and display will still be active.\r\n\r\nI'd go with your strategy *only* in case of significant memory constraints (like < 50mb)."}}
{"actor":{"display_login":"artem-zinnatullin"}}