CPU or I/O bound?

Whether you use Kotlin Coroutines or RxJava, you are used to choose CPU or I/O bound schedulers. Do you know why? Let’s briefly sum up this topic.

CPU bound

CPU bound operation depends on CPU only. It is not waiting for any underlying hardware. Thus it’s incredibly fast and used for computation (e.g. image blurring, …)

  • RxJava: Schedulers.computation()
  • Coroutines: Dispatchers.Default

CPU bound scheduler can have as many threads as there is number of CPUs available. And they are used heavily for computation.

CPU bound algorithms benefits from parallelism, but not from single-core concurrency.

I/O bound

I/O bound operation usually takes longer since it’s waiting (IOWait) for underlying hardware (e.g. handling local file / database / network).

  • RxJava: io Scheduler
  • Coroutines: Dispatchers.IO

I/O bound schedulers can have as many threads as available resources (memory). I/O scheduler means a lot of threads. Majority of those threads are waiting for resources.

I/O bound will always perform better in concurrent implementation than if they are sequential.

Interchange them?

What happen if you use one instead of the other?

Using I/O operations on CPU scheduler? It will block limited thread pool and I/O operations will be slower.

Using computation on I/O scheduler? It will overloads CPU cores and thus slowdown computation.

Monorepo

I decided to start using monorepo for all of my new personal Android projects. Let’s take a look at issues I had with separated repos.

Obsolete codebase

Recently I decided to quit one of my old open source projects [SecurityShowcase] for several reasons (Complete list is written in the repo’s readme) . But one of those reasons was outdated codebase. This is painful with every personal project where I return back after months or even worst after years.

Reuse code

Every time I start to write the new app I repeatedly copy/paste skeleton with all basic core files and every time I have to solve issues when bumping versions.

Save the idea

Every time I play with some specific feature or programming approach, the result ends always wired to some specific app or just thrown away completely.

Monorepo as a solution

All those mentioned issues forced me to think about how to continue with all my habits and write open source with maintainable code base. And I realised that my personal monorepo could be a solution for all the issues listed above.

  • Using one codebase for every piece of contribution ensures repo is always up to date. I agree, that sometimes it might be harder to maintain global codebase.
  • Using one codebase forces project to be well scaled and to have proper testing (to not break anything accidentally).
  • Using modular system for Android project allows to have multiple applications based on the same core/feature modules.
  • Modular system allows to add any idea into up-to-date codebase at any time pretty quickly.
  • Using one codebase will force us to carefully think about existing features whether they are still worth to have them in the repo.

I truly believe to this approach. Let’s see how it will work 🙂

Happy Coding! MJ

Android future, really?

I have been observing Googles activity called Fuchsia for past few years. There is more or less rumours about what language would be supported there or what would be the primary one. Nevertheless the movement for new system running on own hardware is obvious.

Architecture components

Google covers majority of mobile world with Android operating system. And it’s obvious, that this system is in troubles. Android teams introduced Android architecture components. This activity might seems to be the right way to solve issues every Android developer is struggling with. It also seems to make Android development more attractive for everyone.

Patching not fixing

I know, that architecture components takes more and more popularity. But I also can’t overlook what smart people pointed out of this architecture. Whole concept of lifecycle awareness is based on retained fragments (well known trouble makers). ViewModels are complex objects, rather than simple state holders. And there is much more. It seems to me like patching broken system, rather than fixing real cause of troubles.

Successor for Android

This January was confirmed that Android App support had been added to the codebase of Fuchsia. It seems to be more and more obvious, that Google has been preparing shift for the new operation system and it requires to shift also all existing developers with their skills and apps, they have been working so far.

Fuchsia is still in some alpha state and unconfirmed. But there is quite a lot effort behind that. Let’s see Fuchsia subreddit for latest rumours and news. Anyway there is new operation system coming. What will show Google I/O 2019 up? Will there be some official announcement?

Create a website or blog at WordPress.com

Up ↑