Last Updated on September 27, 2023

You can benchmark the performance of coroutines, threads, and processes on a suite of (simulated) common tasks.

This is helpful to explore a refrain that “coroutines are faster than threads“, and the sometimes opposite refrain “threads are faster than coroutines“.

Benchmark results across different common types of tasks show that both threads and coroutines are about as fast as each other, even when the startup time of threads and coroutines is taken into account, at least with a modest number of concurrent tasks, e.g. 100.

In this tutorial, you will discover whether coroutines really are faster than threads, or not, given a suite of benchmarks.

Big thank you to Timothy Beamish for the discussion that prompted this tutorial.

Let’s get started.

Are Asyncio Coroutines Faster Than Threads!?

There is much confusion in the Python community about asyncio vs. threads.

For example, some claim that asyncio is faster than threads, and why we all need to go full asyncio ASAP.

This is often the refrain of the beginner or the newly converted.

Other more seasoned developers claim that threads are faster than asyncio.

For example:

Asyncio will make my code blazing fast. Unfortunately, no. In fact, most benchmarks seem to show that threading solutions are slightly faster than their comparable Asyncio solutions.

— Page 6, Using Asyncio in Python, 2020.

Also see the piece: Async Python is not faster.

The problem with both claims is that they motivate adopting asyncio because of execution speed. This is an error.

We adopt asyncio because we want asynchronous programming in Python and to adopt capabilities like non-blocking I/O with sockets and subprocesses.

You can learn more about this stance in the tutorial:

• Why Python Developers Hate Asyncio

Nevertheless, sometimes the speed of execution is important. The most important.

Sometimes completing many concurrent tasks faster with one approach than another matters.

We will explore the question of whether asyncio coroutines are faster than threads, or not.

Before we do, let’s briefly consider the differences between coroutines and threads.

Coroutines vs Threads

Coroutines and threads are quite different.

A coroutine is a function. A thread is an object connected to a native “thread” in the operating system.

You can learn more about asyncio vs. threads in the tutorial:

• Asyncio vs Threading in Python

These structural differences result in two performance differences that we can state upfront, they are:

1. Coroutines are faster to start than threads.
2. Coroutines use less memory than threads.

Let’s take a closer look at each in turn.

Asyncio Coroutines Are Faster To Start Than Threads

Generally, coroutines are faster to “start” than threads.

This should make sense.

A coroutine is just a function. A thread is a Python object tied to a native thread which is manipulated by an operating system-specific API under the covers.

Running a function is faster than creating an object and calling down to a C API to do things in the OS.

This should not be surprising.

You can learn more about this in the tutorial:

• Coroutines Are Faster To Start Than Threads in Python

The implication is that if all things are equal, e.g. the task takes the same time to execute in a coroutine and in a thread, then the startup time of the unit of concurrency might make coroutines slightly faster.

Yep, this may be.

Generally, my thoughts are:

1. Startup time is still tiny, e.g. sub 2 ms (see below).
2. Startup time is a constant, we exclude/ignore constants when waving our hands about and talking about benchmarking.
3. Startup time can be overcome by using a pool of workers started once and reused.

Asyncio Coroutines Use Less Memory Than Threads

Coroutines use less memory than threads.

This is for the same reason why coroutines are faster to start than threads. They use less memory because they are just functions, whereas Threads and Processes are represented in Python as objects and are connected to very real native threads and processes in the operating system, with all the baggage that entails.

Again, this should not be surprising.

You can learn more about this in the tutorial:

• Coroutines Use Less Memory Than Threads in Python

The upshot is important.

We may want to adopt asyncio because it can support more concurrent tasks than another type of concurrency.

It can “do more” concurrent tasks per unit of concurrency compared to threads and processes if memory requirements per task are a constraint.

This may or may not hold in practice, and there are many benchmark results all over the web, mostly web server-focused, that go either way.

Your mileage may vary. Test.

Benchmark Consistency

The focus here will be the execution time of the same tasks with different units of concurrency.

We will compare coroutines and threads, and rope in processes for good measure.

Benchmarking will aim to be consistent across all tests.

We will aim to complete the same task using coroutines, threads, and processes. Naturally, the asyncio version will use coroutine functions, whereas the thread and process must use normal Python functions.

In all tests, we will create 100 concurrent tasks and wait for them to complete. The coroutine versions will create and await tasks, whereas the thread and process versions will create, start, and join Thread and Process objects.

Each benchmark will be repeated 30 times and the average of the 30 runs reported as the benchmark result for the given unit of concurrency. We take average time to give an expected performance and to counter variation introduced by the operating system, other programs that happen to be running, garbage collection, and so on.

Timing will be recorded using the time.perf_counter() function, preferred over time.time() because it may have higher precision and is not subject to changes to the system clock due to synchronization.

You can learn more about time.perf_counter() in the tutorial:

• Benchmark Python with time.perf_counter()

Yes, we could use the timeit API. I find it cumbersome in practice, and more critically, I find it confusing to readers. Nevertheless, you can adapt the examples below to use the timeit.timeit() API directly if you prefer.

We will explore 5 benchmark use cases that I think attack the central question of coroutines vs threads from a speed/faster perspective, they are:

1. Benchmark fixed duration tasks.
2. Benchmark variable duration tasks.
3. Benchmark startup time only.
4. Benchmark blocking IO-bound task.
5. Benchmark blocking CPU-bound task.

Relax. Don’t take the results as the final word. They’re just another set of empirical results we can talk about.

For reference, all tests were performed with Python 3.11.4 on macOS on a 4.2 GHz Quad-Core Intel Core i7. Take the results as relative and directional of expected performance, rather than absolute and definitive.

Repeat all the tests on your machine and share the results in the comments, I’d love to see if we get the same findings (we should).

Think there is a fatal flaw in the reasoning here? Shout out in the comments, help me to see things the way you do.

Let’s dive in.

Test 01: Benchmark Fixed Duration Tasks

We can explore how coroutines, threads, and processes compare when executing a fixed-duration task.

In this case, the fixed duration task will be a sleep, native to the unit of concurrency.

This means that coroutine tasks will await a call to asyncio.sleep(), whereas threads and processes will call time.sleep().

The expectation is that coroutines, threads, and processes should all have times that are very similar, and dominated by the fixed-duration task. We may expect the processes to take longer given the added time to startup (spawn) child processes compared to starting threads and coroutines.

Example Benchmark with Coroutines

We can benchmark 100 concurrent coroutines with a fixed-duration task that sleeps for 5 seconds.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 5.003148159776659 seconds.

Example Benchmark with Threads

We can benchmark 100 concurrent threads with a fixed-duration task that sleeps for 5 seconds.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 5.007344934732343 seconds.

Example Benchmark with Processes

We can benchmark 100 concurrent processes with a fixed-duration task that sleeps for 5 seconds.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 5.926129415029815 seconds.

Comparison of Results

The table below summarizes the results of executing 100 fixed-duration tasks with coroutines, threads, and processes.

We can see that the overall time is dominated by the duration of the 5-second task, as expected.

We can also see that the timings for coroutines and threads are very similar with a difference of 0.004196774955684 seconds or about 4 milliseconds. This is so tiny that it may be within the margin of measurement error.

We can see that the example with processes is nearly a full second slower than the coroutine example, e.g. 0.922981255253156 seconds. This was expected as generally spawning child processes is significantly slower than starting threads and coroutines.

Test 02: Benchmark Variable Duration Tasks

We can explore how coroutines, threads, and processes compare when executing a variable-duration task.

In this case, the variable duration task will be a sleep for a fraction of 5 seconds determined by a pseudorandom number generator random.random(). No care will be taken to ensure the thread safety of the random numbers. Maybe this is sloppy, but I think it has no bearing (prove me wrong?).

A native sleep will be used for each method of concurrency. This means that coroutine tasks will await a call to asyncio.sleep(), whereas threads and processes will call time.sleep().

The expectation is that the overall group of tasks will take as long as the longest duration task, which will be nearly a full fraction of 5 seconds. This duration will dominate the timing. Again, the long start-up time of processes will make the execution time using child processes longer than either coroutines or threads.

The expectation is that the timing of threads and coroutines will be similar, perhaps separated by random variability in the task durations.

Example Benchmark with Coroutines

We can benchmark 100 concurrent coroutines with a variable-duration task that sleeps for a fraction of 5 seconds.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 4.9519578189007 seconds.

Example Benchmark with Threads

We can benchmark 100 concurrent threads with a variable-duration task that sleeps for a fraction of 5 seconds.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 4.961258380332341 seconds.

Example Benchmark with Processes

We can benchmark 100 concurrent processes with a variable-duration task that sleeps for a fraction of 5 seconds.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 5.741915735187164 seconds.

Comparison of Results

The table below summarizes the results of executing 100 variable-duration tasks with coroutines, threads, and processes.

We can see that as expected, in all cases timing is dominated by the longest task which is a major fraction of 5 seconds.

We can see that the timing of coroutines and threads are very similar, as expected. The difference is only about 0.009300561431641 seconds or about 9 milliseconds in favor of coroutines.

We can see that again that using processes was nearly a second slower than threads and processes as we expected given the slow start-up time, e.g. 0.789957916286464 seconds slower than coroutines.

This highlights that our expectations are holding so far with fixed and variable duration tasks, coroutines and threads perform about the same from an execution time perspective.

Test 03: Benchmark Startup Time Only

We can explore how coroutines, threads, and processes compare when executing an empty task.

This will compare task start-up time only.

We know from previous experiments that coroutines start faster than threads because coroutines are a type of a function whereas threads are a Python object (and concept) in the underlying operating system.

You can learn more about this in the tutorial:

• Coroutines Are Faster To Start Than Threads in Python

Nevertheless, we have a robust test harness in this tutorial, so let’s use it and confirm the findings.

Example Benchmark with Coroutines

We can benchmark 100 concurrent coroutines with an empty task to test start-up time.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 0.004739730646057675 seconds.

Example Benchmark with Threads

We can benchmark 100 concurrent threads with an empty task to test start-up time.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 0.0061288173349263765 seconds.

Example Benchmark with Processes

We can benchmark 100 concurrent processes with an empty task to test start-up time.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 1.1669189567444846 seconds.

Comparison of Results

The table below summarizes the results of executing 100 empty tasks with coroutines, threads, and processes.

We can see that as we expected, the timing shows that coroutines are slightly faster than threads. The difference is about 0.001389086688869 seconds or about 1.3 milliseconds.

This is less than the difference seen above of 4 and 9 milliseconds for fixed-duration and variable-duration tasks respectively. The difference is tiny.

Perhaps within the margin of measurement error.

Perhaps the interpreter optimizes the empty tasks away in some cases.

We can see that as expected processes are much slower to start than both threads and coroutines, more than a second in both cases, e.g. 1.162179226098427 seconds slower than coroutines.

I suspect this is a more fair test than the prior work and shows the difference in starting time between threads and processes, at least 100 units, is barely measurable.

Test 04: Benchmark Many Short Blocking IO-Bound Calls

We can explore how coroutines, threads, and processes compare when executing a blocking IO-bound function call.

In this case, we will use the time.sleep() function with zero seconds. We will execute this call in a loop and repeat the task 10,000 times.

Calling time.sleep() in coroutines will block the event loop and we expect to make 10,000 calls in time.sleep(0) will impact the overall time of 100 coroutines negatively, forcing all 100 tasks to execute sequentially rather than concurrently.

Calling time.sleep(0) in Python threads and processes is expected to signal to the operating system to context switch, which the OS may or may not act upon. I suspect that the aggressive looping of 10,000 calls will result in a lot of context switching, perhaps negatively impacting the performance of threads and processes, but not preventing them from executing concurrently.

My thinking was that this might be a rare use case where threads and processes might outperform the coroutine version.

We can estimate the time of one task using timeit, for example on the command line:

This reports the results:

It suggests that one task takes about 5 milliseconds, therefore if 100 tasks are executed sequentially then it should take about 5 * 100 or 500 milliseconds or 0.5 seconds. Less than this, then some parallelism was achieved.

Example Benchmark with Coroutines

We can benchmark 100 concurrent coroutines with a task that loops 10,000 calls to time.sleep(0).

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 0.4891133862081915 seconds.

Example Benchmark with Threads

We can benchmark 100 concurrent threads with a task that loops 10,000 calls to time.sleep(0).

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 4.327525828394573 seconds.

Example Benchmark with Processes

We can benchmark 100 concurrent processes with a task that loops 10,000 calls to time.sleep(0).

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 1.1696696432229752 seconds.

Comparison of Results

The table below summarizes the results of executing 100 tasks that loop 10,000 times with calls to time.sleep(0) using coroutines, threads, and processes.

The results surprised me.

I expected coroutines to be slower than threads because of the sequential execution of all 100 tasks. Instead, we can see that coroutines were faster than threads with a difference of 3.838412442186382 seconds.

Nevertheless, the coroutines took as long as we expected from a theoretical perspective to execute all 100 tasks sequentially, e.g. about half a second.

When it comes to the threads, I suspect that the operating system context switches the threads like crazy and that the overhead of so much context switching was worse than executing all 100 tasks sequentially in the asyncio event loop. Fascinating.

We can also see that the processes outperformed the threads, in this case by about 3.157856185171598 seconds.

So if the theory that threads context switched like crazy is the reason why threads performed so badly here, then why didn’t processes show the same effect? Child processes execute the task in a main thread. Is the request to context switch less likely to be honored if there is only a single thread in the process rather than 100? I doubt it.

More work is needed to understand this finding.

Test05: Benchmark Many Short CPU-Bound Calls

We can explore how coroutines, threads, and processes compare when executing a blocking CPU-bound function call.

In this case, we will create a list of one million squared integers in a list comprehension, for example:

This is a CPU-bound task and a blocking call.

The expectation is that it will block the asyncio event loop and cause all coroutines to execute their tasks sequentially instead of concurrently.

Further, the expectation is that it will block the GIL and cause all threads to execute their tasks sequentially instead of concurrently.

Perhaps this will mean that threads and coroutines will perform similarly in this case.

The expectation is that processes will execute the task concurrently and in parallel given the one GIL per process, but perhaps the one-second overhead of starting the child processes may overwhelm any benefit.

We can time the snippet with timeit, for example from the command line:

This gives:

So, we can expect that each task will take about 60 milliseconds.

A total of 100 tasks will take 100*60 or 6,000 milliseconds or 6 seconds to complete sequentially, and this may be the expected time to complete all tasks with coroutines and threads.

Example Benchmark with Coroutines

We can benchmark 100 concurrent coroutines with a CPU-bound task.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 6.203456498515637 seconds.

Example Benchmark with Threads

We can benchmark 100 concurrent threads with a CPU-bound task.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 5.568172295178131 seconds.

Example Benchmark with Processes

We can benchmark 100 concurrent processes with a CPU-bound task.

The complete example is listed below.

Running the example, we can see that the average time to complete all tasks is about 2.660895350195157 seconds.

Comparison of Results

The table below summarizes the results of executing 100 tasks that create a list of one million squared integers with coroutines, threads, and processes.

We can see that the results for coroutines match the theoretical expectation of 100 tasks executed sequentially, e.g. about 6 seconds.

Interestingly, we can see that the threads were faster than coroutines in this case, faster by about 0.635284203337506 seconds.

This is surprising, I expected both coroutines and threads to have very similar performance. Nevertheless, the finding is inconsequential, we do not want to execute CPU-bound tasks in this way, e.g. sequentially by blocking the event loop and blocking the GIL.

Why? I expect switching between blocking tasks in the event loop to be faster than context-switching threads in the OS. Maybe this assumption is wrong. We are switching sequentially in the event loop as each task is completed. The OS is probably doing the same thing, but maybe not.

As we expected, using processes was the fastest because processes can achieve full parallelism, with one GIL per child process.

Another good reminder, if we needed it, is that pure-Python CPU-bound tasks should be executed with multiprocessing, probably in a process pool or ProcessPoolExecutor.

Review and Analysis

What did we find?

Coroutines are not faster than threads. They perform about the same.

Well, maybe coroutines are slightly faster to start, in the order of a few milliseconds, but this might be within the bounds of measurement error. If I could be bothered I’d spin up my stats and comment on the means and the standard error. Not today.

Remember, we don’t reach for asyncio and coroutines because they are faster than threads.

We reach for asyncio and coroutines for other reasons, like:

• We want (or are forced by an API) to do asynchronous programming in Python.
• We want the scalability offered by units of concurrency that use less memory.
• Other reasons.

For more on this, see the tutorial:

• 6 Reasons to Use Asyncio

We did discover that threads go crazy in one process when requested to context switch a ton with time.sleep(0) calls. Maybe the test design was bad and we found some strangeness, I bet on this. A better test might be to have all tasks read an OS file and count bytes, e.g. a real blocking I/O bound task.

We did discover that even with the GIL, threads can do slightly better than coroutines when abused to execute many CPU-bound tasks concurrently. I think the finding is real and that some quote threads doing better are testing in this kind of scenario (e.g. not going async “all the way down“). Not sure it matters here as we are misusing threads and coroutines for an inappropriate task.

This was fun.

Thoughts?

Further Reading

This section provides additional resources that you may find helpful.

Python Asyncio Books

• Python Asyncio Mastery, Jason Brownlee (my book!)
• Python Asyncio Jump-Start, Jason Brownlee.
• Python Asyncio Interview Questions, Jason Brownlee.
• Asyncio Module API Cheat Sheet

I also recommend the following books:

• Python Concurrency with asyncio, Matthew Fowler, 2022.
• Using Asyncio in Python, Caleb Hattingh, 2020.
• asyncio Recipes, Mohamed Mustapha Tahrioui, 2019.

Guides

• Python Asyncio: The Complete Guide
• Python Asynchronous Programming

APIs

• asyncio — Asynchronous I/O
• Asyncio Coroutines and Tasks
• Asyncio Streams
• Asyncio Subprocesses
• Asyncio Queues
• Asyncio Synchronization Primitives

References

• Asynchronous I/O, Wikipedia.
• Coroutine, Wikipedia.

Takeaways

You now know that threads and coroutines perform about the same on average.

Did I make a mistake? See a typo?
I’m a simple humble human. Correct me, please!

Do you have any additional tips?
I’d love to hear about them!

Do you have any questions?
Ask your questions in the comments below and I will do my best to answer.

Photo by Kenny Eliason on Unsplash