Everything is labeled out here : <https://github.com/AnonymousGeekDev/FastLightJP2/blob/coroutine-op...

# coroutines

[Glen]

Everything is labeled out here : https://github.com/AnonymousGeekDev/FastLightJP2/blob/coroutine-optimized/app/src/main/java/com/example/jp2ssr/kotlin/MainActivity.kt

[Tijl]

private val uiScope : CoroutineScope = CoroutineScope(Dispatchers.Main) <-- you’re processing on a single UI thread

your measure function is wrong though, you’re measuring the launch, only potentially the actual work

[Glen]

OK, @Tijl, so how do I make the measuring function more accurate?

[Tijl]

measure the actual work.

[Glen]

Please, can you give me a hint?

[Tijl]

it depends on which work you want to measure (I can’t tell you that, since that is up to you), but since you’re complaining about ASyncTask, and now you are measuring something that’s not comparable to anything in AsyncTask (only the launch of the coroutine) I doubt that is what you want measure

[Tijl]

if you don’t understand what launch does, you can find a basic tutorial on coroutines, they pretty much all explain it.

[Glen]

As for the scope, if you look at the function here , it delegates work to another Dispatcher for the background work, except I am doing it wrong.

[Glen]

Any thoughts, @Tijl, or anyone?

[wasyl]

The withContext(Dispatchers.Default) does move the heavy work to background thread so that should be correct.
Also I’m not 100% sure but I think measureTimeMillis should work as well, since launch only returns once all the work inside is finished. (I was wrong, see later comments)
Can you elaborate on “results I obtain with AsyncTask are better”? Is AsyncTask version faster? If so, how much faster?

[Tijl]

that doesn’t mean you are not telling it to go to the UI thread. From UI thread back to Default, back to UI thread is not free

[bezrukov]

dispatcher's concurrency doesn't matter a lot here because all processing code is blocking and you don't use concurrency at all. I don't think you will see any "performance boost" just by switching from one async model to another without adoption/parallelization

[Glen]

So, @bezrukov, how do you propose I tackle the issue?

[Glen]

@wasyl, for example, the execution time for coroutines is at least 4 times that of AsyncTask.

[Glen]

Not much difference in CPU usage also.

[Tijl]

using your invalid measuring function?

[Glen]

Yeah, @Tijl. Please could you provide an example of a more accurate measuring function?

[Tijl]

I assume you don’t want to measure launch, I don’t know what you do want to measure. But for example a measureTimeMillis after withContext(Dispatchers.Default){ would correctly measure how long decoding an image would take. I don’t know why you would want to measure that, but it’s an example of correctly measuring something.

[Glen]

OK. I will try your suggestion.

[bezrukov]

I wonder why it is not 0ms 🙂

[Glen]

@bezrukov, you tested it?

[bezrukov]

nope, just launch should end almost instantly. What is your numbers? I can't believe that launch will take at least 4ms (to be 4x time slower than async task) with the current measuring

[Glen]

@bezrukov, with AsyncTask, I obtain 5ms. With coroutines, I obtain 15ms.

[Glen]

When testing on one person' device, coroutines gave me consistent 0ms and 1ms times, but on all other devices I have tested, the results are different.

[Glen]

By the way, @bezrukov, the AsyncTask version, is in the main branch of the repo.

[bezrukov]

with asynctask you are measuring the time in a wrong way too, you're measuring execute time. You need to measure doInBackground time instead (even better to measure the time between onPreExecute and onPostExecute).

As of coroutines you need to measure the time inside the `launch`:

uiScope.launch {
    val time = measureTimeMillis { 
        val processedImage = processImage(imgView)

        imgView.setImageBitmap(processedImage)
    }
    // print time
}

your current measuring doesn't provide any meaningful info about the consumed time.

But again, as I said in both asynctask/coroutines implementation your processing is blocking and singlethreaded and I don't think you will be able to improve this without digging into decoding process and parallelization it.

[Tijl]

throw in an @jamesgoslin while you’re at it 🤣

[Glen]

OK. So @bezrukov, the parallelization should be done at a library level?

[Glen]

Please, anyone, could the error be associated with the version of the library I am using?

[Glen]

Hello everyone. Please can anyone give me hints on how to measure the execution time of those functions correctly?