CODEWITHSUNDEEP
multithreadingkotlinkotlin-coroutines
arifng
arifng

Reputation: 776

Is it better to use a thread or coroutine in Kotlin?

I'm sending mail from an application. As mail sending takes time and blocking the main thread, I'm creating a new thread and hand over the mail sending task to the new thread. For lots of concurrent request to send mail, I have to create lots of thread. But creating thread seems to be slow.

My question is if I use Kotlin's coroutine, does it give better performance than thread?

Some sort of explanations or hints is highly appreciable.

Upvotes: 9

Views: 7843

Answers (4)

Marko Topolnik
Marko Topolnik

Reputation: 200148

My question is if I use Kotlin's coroutine, does it give better performance than thread?

Coroutines aren't a snap-in replacement for threads. The fundamental difference is in the kind of API you're using. The rule of thumb is this:

  • blocking API -> use a thread pool
  • non-blocking (async) API -> use coroutines

So, if you can get a hold of an asynchronous mail-sending API, then by all means use coroutines with it. But if you're stuck with a blocking API, coroutines won't bring you much value. They can make it a bit more convenient to transfer a blocking operation out of the UI thread, but the mechanics will be the same with or without coroutines.

Upvotes: 5

Matt Timmermans
Matt Timmermans

Reputation: 59174

You should pretty much always use coroutines to manage concurrency in Kotlin.

If you have to make a lengthy blocking call, though, it's going to block a thread no matter what, and you should make sure that it doesn't block a thread that could stall your application.

In Kotlin, when you need a coroutine to run on a different or special thread, you use a "dispatcher", which pretty much equivalent to a thread pool. Dispatchers.IO is provided specifically for the purpose of running lengthy blocking I/O operations like sending email.

Using it is as easy as:

withContext(Dispatchers.IO) {
    sendEmail(...)
}

Upvotes: 10

Alexey Soshin
Alexey Soshin

Reputation: 17701

TL;DR - always use coroutines while working in Kotlin

Threads have a relatively large memory footprint - around 1MB of VM memory for each thread. If you create a thread per task, you're risking simply running out of memory. Coroutines, in comparison, are relatively small, taking a few KB of VM's memory.

Creation of a new thread is relatively slow, since it goes through OS. Operation system doesn't know anything about coroutines, so spawning a new one is relatively fast.

For the same reason, context switching between threads is much more expensive than context switching between suspended coroutines.

In addition, coroutines are less prone to leaks, thanks to structured concurrency.

Upvotes: 14

Neo
Neo

Reputation: 2039

Highly discussable question. My answer is based on my own experience and few web-links to well known references.

If you're writing in Kotlin, I would always use coroutines.

1. Performance

baeldung.com

Creating too many threads can actually make an application underperform in some situations; threads are objects which impose overhead during object allocation and garbage collection.

To overcome these issues, Kotlin introduced a new way of writing asynchronous, non-blocking code; the Coroutine.

Similar to threads, coroutines can run in concurrently, wait for, and communicate with each other with the difference that creating them is way cheaper than threads.

There are many other websites and statistics proving the point, that having coroutines is much cheaper than using java threads.

From my own experiences - I build an application in my company for logistics which has at some point of runtime over 20 coroutines running in parallel - I never had in 1,5 years of using them any 'OutOMemory', 'StackOverflow', or 'slowing down the main application' problems.

2. Usability / Difficulty

Compared to java Threads, using Kotlin coroutines is very easy and doesn't enforce you to change the way you code. The last point is well explained in this video.

Usually working in Java with Java threads, people built so many 'procedures' or classes to add safety with multi-threading, that it creates a big overhead of things to know about before you do real good multi-threading. And it takes alot of time.

In Kotlin its easy: you don't need Thread pools or twerking the code to make it asynchronous - you just do it with easy keyword async.

Upvotes: 2

Related Questions