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.
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(...)
}
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.
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:
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.
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.
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.
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.