w.brian
w.brian

Reputation: 17367

How much of a performance hit is there when calling async methods that are immediately waited on?

A lot of API's are moving toward exposing only asynchronous methods. How much of a performance hit is there in scenarios where you have to immediately wait on these methods? Am I wrong in assuming that it causes the current thread to wait on a spawned thread to complete? Or does the CLR perform some sort of magic in these scenarios and make it all execute in the same thread?

Upvotes: 0

Views: 274

Answers (1)

Eren Ersönmez
Eren Ersönmez

Reputation: 39085

By "asynchronous methods", I assume you mean Task<T> based async methods.

So if you have a method that returns a Task<T> and you immediately call its Wait() method, that causes the current that to wait on an internal WaitHandle object. The task most likely executes on a different thread and signals the WaitHandle when completed, which releases the waiting thread. There is no compliler optimization that turns this scenario into a synchronous call that I'm aware of.

This is of course more work than just calling a synchronous equivalent of the async method. However,depending on your use case, it probably won't be a significant difference.

The more important question is why would you want to loose the advantages of async by blocking the calling thread? That is generally not a good idea, you should ensure you have a very good reason to do this.

Upvotes: 3

Related Questions