6 ms·

Out of interest, how many people here actually use async methods? Excluding being forced to by a library. They haven't revolutionized my code at all. I can't d

Out of interest, how many people here actually use async methods? Excluding being forced to by a library. They haven't revolutionized my code at all. I can't decide if I'm too stupid to realize when to use them, or if they're really just a bit useless for most normal code. I can see the point to it, it's just that most of the time I'd consider using it, it just isn't worth the extra effort. Usually seems to be a premature optimization. Lambda expressions, now they revolutionized my code completely.

tracker1 11y ago
It isn't the end of the world in .Net but it will be the difference between a server handling fewer than 10K simultaneous requests and over 100K on modern hardware. In general, as much as possible service could should be async... That said, a lot of code isn't. The breakup of the request pipeline and thread pooling in ASP.Net make it slightly less necessary, as it's still very efficient. That said, you should probably introduce it using Parallel Linq as much as possible, and/or when you need to consume multiple resources in a given request. If you're writing stand alone applications, and already using threads/thread pools, then it's probably less of an impact. If you're writing server/service applications then it does make a difference in terms of scalability.
- mattmanser 11y ago
  But that's kinda my point, I don't use it because it makes the code more complicated, it's a premature optimization. C# is already blazingly fast. To put it in context, 10K simultaneous requests is 10 billion page views per day (10000 * 10 * 60 * 60 * 24, assuming 100ms processing time, which is actually pretty high for .Net, mine are usually 60ms even on crap hardware. Yes it's a silly calculation, but it gives you an idea about the scale we're talking about). If you're at that scale, you can afford to hire John Skeet to go back over your code and add a few `async`s into it where appropiate. From what you just said it seems that anyone using it all the time is unnecessarily cluttering their code.
  - tracker1 11y ago
    I don't think that it's really a matter of cluttering code all that much... the keyword implies the intent and should be relatively easy to understand. Then again, I've spent about half my time in node the past few years, and getting async/await with babel makes the world easier to use. Also, It's not like it doesn't do you any good. With async you may be able to reduce the size of your cloud instances, as an example... saving money in the end. Doesn't mean as much if you have a dedicated server, or existing codebase though. If you're doing a green web project, you should probably use async from the start. In general, denormalizing and caching data, and using async requests are what improves overall responsiveness in an application. Async allows for a given request to have more than one outbound IO statement waiting for a response, and return the aggregate together.
    - mattmanser 11y ago
      Yes, but how many C# projects ever need that scale? If it's an internal enterprise app, the bread and butter of C# apps, it's a totally useless optimization. It wouldn't reduce the size at all. The kind of web scale business that should be using async, let's be frank, those kind of projects don't use C#. Go look at the YC list of technology, not a single C# user on there. If that's all you the benefit of using async is, it hopefully looks like I'm ok not using it.
      - tracker1 11y ago
        But even in the enterprise responsiveness is appreciated... if you're making multiple calls on the backend... resource authentication, related item lookup, and other services, if you can run all of these requests asynchronously, then it's the max of those items plus a little overhead for conjunction... not using async is the aggregate... it's the difference between a sub-100ms response, or over... 100ms is nearly transparent, more than that is not. I don't disagree that it isn't that much of a benefit in many cases, but tbh if I'm to chose between async usage and, for example ever seeing EntLib Data classes, or a DI/IoC tool when no testing is being done, I'll take async. There are plenty of practices in C#/.Net shops that are just hideous to work with, async imho isn't one of them.
norea-armozel 11y ago
I can't think of a perfect example for using async other than imagining your application is pulling in stock ticker quote on demand. Some of those quotes will be old so you have some logic that removes them so to keep the ticker marquee fresh. While the method responsible for culling ticker quotes need not be asynchronous the method responsible for getting the ticker quotes themselves may be best suited for an asynchronous call if the data source is remote (like a web service). This way the rest of your application can still do whatever tasks that are essential while the ticker quotes trickle in from the async method. You just have to deal with the possibility that when it times out you'll have a gap in the data being displayed which is trivial by comparison to writing the entire application synchronously where any minor delay can stop its operation.
- tracker1 11y ago
  Highly cache-friendly data that can tolerate being slightly stale should be cached or kept in application memory, where the most recent version is returned. In this case, if the data is being used from a foreign source, then a separate thread processing a stream of incoming data that updates a shared/static state may be best. Requests as part of a Service pipeline are best served as async. User -> http -> service endpoint <(requests to db's, and another service as async)> -> async response In general, if you are IO bound (waiting on IO/service responses), then you will be well served with async. As part of a service pipeline that will access multiple backend resources it makes a lot of sense. If you can share/cache foreign data sources, it makes less sense. Cache first, other optimization strategies second and as needed. Unless it's a green project, then try to be async from the start.
Renevith 11y ago
It sounds like you're talking about multithreading in general rather than async specifically. If you don't need multithreading then you don't need async... that's not too surprising. I write an application that previously wasn't using threading to avoid blocking the UI. Certain long-running tasks would freeze the app for some time. It's not a big deal since it's an internal app for my work team, but now that the async syntax and semantics are a bit easier, I've started using them and my app is more responsive. Async doesn't do anything fundamentally new. If you already implemented multithreading in your application that you're happy with, there's no compelling reason to switch to doing it the async way. But for new development it seems like it should be the default.
- mattmanser 11y ago
  I thought WPF did that for you? I only ever used Silverlight but I seem to remember the UI was on a different thread to the rest of it anyway.
- edgyswingset 11y ago
  > Async doesn't do anything fundamentally new. This is correct, but not in the way you're describing. The API calls that it ultimately makes have been in place before C# 5. C# 5 just made writing that kind of code significantly simpler than it was before. > If you already implemented multithreading in your application that you're happy with, there's no compelling reason to switch to doing it the async way. This isn't necessarily true. From the perspective of a client application, it's less resource-intensive to use async code than to spin up another thread. On mobile devices that's less battery life used, which is always a good thing. From the perspective of a server, multithreading only gets you so far, plus they can eat up tons of memory in the process. Async code does not spin up new threads and allows for spikes in traffic to be handled gracefully rather than (a) using tons of threads, or (b) being unable to handle the load at all.
jorgeleo 11y ago
A pattern that i am finding a lot is using await on a single call async Task, so it pauses the current thread waiting for that single call to finish in another thread. It looks like multithreaded code, it taste like using multithread technics, but it is sequential code with thread jumping. The only benefit that I have found is that in winforms apps the call to back end does not block the ui thread. Otherwise it is just silly. On the code revolutions, lambda expressions and half implemented linq. I call it half implemented because I am missing the ability to yield return to 2 separate IEnumerables from inside the same method, think results and errors.
edgyswingset 11y ago
Think of it this way: What happens when IIS runs out of threads? Without async code, it queues of requests and users sit there getting nothing from your server. With async code, that's not the case! Well, until you reach the limit of what async code does, but that limit is quite high. Typically a request thread that ends up blocking on I/O in some way (like accessing a database) sits there doing absolutely nothing for a very long time. The time it takes to get data from a database could be spent servicing many, many more requests! Async does just that. And before you ask, it doesn't spawn off any threads ... it leverages the asynchronous nature of the operating system to service I/O requests. It's actually really, really rad. > Usually seems to be a premature optimization If you have a user-facing system, it's most definitely not a premature optimization. If you know, for a fact, that you'll never need to worry about responsiveness, they're not worth it.
- louthy 11y ago
  There are 32,768 threads in the thread-pool on a 64bit machine. How many do you need?
  - edgyswingset 11y ago
    > How many do you need? That's an irrelevant question until you legitimately need to scale out. Async code lets you scale up so that when 32,769 users access a site relatively at the same time, you don't force a user to wait for IIS to free up a new thread.
    - louthy 11y ago
      > 'to wait for IIS to free up a new thread.' Apologies if I'm not following your train of thought here. The thread-pool has the threads right, not IIS? When you do something like Task.Run(...) the task-scheduler will schedule your work on a thread-pool thread (32,768 pre-allocated at start-up). Of course you have to wait for the scheduler to give you one of the threads from the pool. Are you saying async doesn't need threads/TPL? I know it has some funky concurrency stuff that allows interleaved processing (rather than thread-pool processing), is this what you're referring to? Even IO would have to do something like this behind the scenes: Result IOMethod() { EventWaitHandle wait = new AutoResetEvent(false); // Do your IO - pass in the handle wait.WaitOne(); return result; } Wouldn't the pre-IO and post-IO need to be run via the scheduler if you want it to run asynchronously? The WaitOne will release the thread back to the pool. How is async any different?
UK-AL 11y ago
I use it to stop any long running io blocking my thread.
alimbada 11y ago
The async features are nice for when you need them, but just because the functionality exists doesn't mean you should use it all over the place (sounds like you aren't anyway :)). A good developer will know when/where to use async.
jayd16 11y ago
The style is great if you have a main thread you need to keep fast and responsive.
mhomde 11y ago
Async methods are mainly used in .Net apps that use an UI-thread paradigm since you avoid blocking the UI thread for things like IO calls
breischl 11y ago
Async is fantastic if you do a lot of I/O and you have to scale. For instance if you have a web service that makes a lot of network calls. In our particular case, and oversimplifying, the app is a smart router. Take a request, farm out pieces of it to multiple other servers, aggregate responses. Some of those requests finish in 5ms, some take several seconds, which is a crappy pattern to deal with. Today's not a particularly busy day, so we're doing about 70 req/sec/VM at 5% CPU on a dual core VM. In load tests I've had it up to 300 req/sec/VM with no problems. It actually bottlenecked our 10Gb network cards before the the CPU maxed out. I haven't tried running the actual app without async because it would be a major rewrite. But I did some benchmarking making lots of parallel HTTP calls with threads vs async, and found that async was 10-20x faster and used less CPU.
useerup 11y ago
> Out of interest, how many people here actually use async methods? Excluding being forced to by a library. We use it almost exclusively. Because of the new async/await syntax it is (almost) as easy to write and get correct as non-async code. Async/await makes an entire class of problems go away (and, ok, swaps it for a class of easier-to-solve problems). In a web application you always need to consider how your application will be impacted by the traffic. Are all of your requests served within 50 milliseconds? Fine, then you do not need async. Do your handlers ever call out to an external site or even a local database where it may block for more than 50 milliseconds? Then you need to consider what happens when almost all of the requests block at at same time: A colossal waste of resources. Traditionally we have handled this by increasing the number of threads we allow the server to use for serving requests. However, threads are expensive in overhead (memory, cpu for context switching) and it affects the footprint of your application, and with that how dense you can pack virtual servers. Enter async: When a request blocks on an external call (to an external site, database etc), the request relinquishes the thread which will be used to serve other requests. What's more: The more you use async/await, the more the application will auto-scale. It will only start new threads when there's actual work to be done rather than when there's waiting to be done.

tracker1 11y ago

It isn't the end of the world in .Net but it will be the difference between a server handling fewer than 10K simultaneous requests and over 100K on modern hardware. In general, as much as possible service could should be async... That said, a lot of code isn't. The breakup of the request pipeline and thread pooling in ASP.Net make it slightly less necessary, as it's still very efficient. That said, you should probably introduce it using Parallel Linq as much as possible, and/or when you need to consume multiple resources in a given request. If you're writing stand alone applications, and already using threads/thread pools, then it's probably less of an impact. If you're writing server/service applications then it does make a difference in terms of scalability.

mattmanser 11y ago
But that's kinda my point, I don't use it because it makes the code more complicated, it's a premature optimization. C# is already blazingly fast. To put it in context, 10K simultaneous requests is 10 billion page views per day (10000 * 10 * 60 * 60 * 24, assuming 100ms processing time, which is actually pretty high for .Net, mine are usually 60ms even on crap hardware. Yes it's a silly calculation, but it gives you an idea about the scale we're talking about). If you're at that scale, you can afford to hire John Skeet to go back over your code and add a few `async`s into it where appropiate. From what you just said it seems that anyone using it all the time is unnecessarily cluttering their code.
- tracker1 11y ago
  I don't think that it's really a matter of cluttering code all that much... the keyword implies the intent and should be relatively easy to understand. Then again, I've spent about half my time in node the past few years, and getting async/await with babel makes the world easier to use. Also, It's not like it doesn't do you any good. With async you may be able to reduce the size of your cloud instances, as an example... saving money in the end. Doesn't mean as much if you have a dedicated server, or existing codebase though. If you're doing a green web project, you should probably use async from the start. In general, denormalizing and caching data, and using async requests are what improves overall responsiveness in an application. Async allows for a given request to have more than one outbound IO statement waiting for a response, and return the aggregate together.
  - mattmanser 11y ago
    Yes, but how many C# projects ever need that scale? If it's an internal enterprise app, the bread and butter of C# apps, it's a totally useless optimization. It wouldn't reduce the size at all. The kind of web scale business that should be using async, let's be frank, those kind of projects don't use C#. Go look at the YC list of technology, not a single C# user on there. If that's all you the benefit of using async is, it hopefully looks like I'm ok not using it.
    - tracker1 11y ago
      But even in the enterprise responsiveness is appreciated... if you're making multiple calls on the backend... resource authentication, related item lookup, and other services, if you can run all of these requests asynchronously, then it's the max of those items plus a little overhead for conjunction... not using async is the aggregate... it's the difference between a sub-100ms response, or over... 100ms is nearly transparent, more than that is not. I don't disagree that it isn't that much of a benefit in many cases, but tbh if I'm to chose between async usage and, for example ever seeing EntLib Data classes, or a DI/IoC tool when no testing is being done, I'll take async. There are plenty of practices in C#/.Net shops that are just hideous to work with, async imho isn't one of them.

norea-armozel 11y ago

I can't think of a perfect example for using async other than imagining your application is pulling in stock ticker quote on demand. Some of those quotes will be old so you have some logic that removes them so to keep the ticker marquee fresh. While the method responsible for culling ticker quotes need not be asynchronous the method responsible for getting the ticker quotes themselves may be best suited for an asynchronous call if the data source is remote (like a web service). This way the rest of your application can still do whatever tasks that are essential while the ticker quotes trickle in from the async method. You just have to deal with the possibility that when it times out you'll have a gap in the data being displayed which is trivial by comparison to writing the entire application synchronously where any minor delay can stop its operation.

tracker1 11y ago
Highly cache-friendly data that can tolerate being slightly stale should be cached or kept in application memory, where the most recent version is returned. In this case, if the data is being used from a foreign source, then a separate thread processing a stream of incoming data that updates a shared/static state may be best. Requests as part of a Service pipeline are best served as async. User -> http -> service endpoint <(requests to db's, and another service as async)> -> async response In general, if you are IO bound (waiting on IO/service responses), then you will be well served with async. As part of a service pipeline that will access multiple backend resources it makes a lot of sense. If you can share/cache foreign data sources, it makes less sense. Cache first, other optimization strategies second and as needed. Unless it's a green project, then try to be async from the start.

Renevith 11y ago

It sounds like you're talking about multithreading in general rather than async specifically. If you don't need multithreading then you don't need async... that's not too surprising. I write an application that previously wasn't using threading to avoid blocking the UI. Certain long-running tasks would freeze the app for some time. It's not a big deal since it's an internal app for my work team, but now that the async syntax and semantics are a bit easier, I've started using them and my app is more responsive. Async doesn't do anything fundamentally new. If you already implemented multithreading in your application that you're happy with, there's no compelling reason to switch to doing it the async way. But for new development it seems like it should be the default.

mattmanser 11y ago
I thought WPF did that for you? I only ever used Silverlight but I seem to remember the UI was on a different thread to the rest of it anyway.
edgyswingset 11y ago
> Async doesn't do anything fundamentally new. This is correct, but not in the way you're describing. The API calls that it ultimately makes have been in place before C# 5. C# 5 just made writing that kind of code significantly simpler than it was before. > If you already implemented multithreading in your application that you're happy with, there's no compelling reason to switch to doing it the async way. This isn't necessarily true. From the perspective of a client application, it's less resource-intensive to use async code than to spin up another thread. On mobile devices that's less battery life used, which is always a good thing. From the perspective of a server, multithreading only gets you so far, plus they can eat up tons of memory in the process. Async code does not spin up new threads and allows for spikes in traffic to be handled gracefully rather than (a) using tons of threads, or (b) being unable to handle the load at all.

jorgeleo 11y ago

A pattern that i am finding a lot is using await on a single call async Task, so it pauses the current thread waiting for that single call to finish in another thread. It looks like multithreaded code, it taste like using multithread technics, but it is sequential code with thread jumping. The only benefit that I have found is that in winforms apps the call to back end does not block the ui thread. Otherwise it is just silly. On the code revolutions, lambda expressions and half implemented linq. I call it half implemented because I am missing the ability to yield return to 2 separate IEnumerables from inside the same method, think results and errors.

edgyswingset 11y ago

Think of it this way: What happens when IIS runs out of threads? Without async code, it queues of requests and users sit there getting nothing from your server. With async code, that's not the case! Well, until you reach the limit of what async code does, but that limit is quite high. Typically a request thread that ends up blocking on I/O in some way (like accessing a database) sits there doing absolutely nothing for a very long time. The time it takes to get data from a database could be spent servicing many, many more requests! Async does just that. And before you ask, it doesn't spawn off any threads ... it leverages the asynchronous nature of the operating system to service I/O requests. It's actually really, really rad. > Usually seems to be a premature optimization If you have a user-facing system, it's most definitely not a premature optimization. If you know, for a fact, that you'll never need to worry about responsiveness, they're not worth it.

louthy 11y ago
There are 32,768 threads in the thread-pool on a 64bit machine. How many do you need?
- edgyswingset 11y ago
  > How many do you need? That's an irrelevant question until you legitimately need to scale out. Async code lets you scale up so that when 32,769 users access a site relatively at the same time, you don't force a user to wait for IIS to free up a new thread.
  - louthy 11y ago
    > 'to wait for IIS to free up a new thread.' Apologies if I'm not following your train of thought here. The thread-pool has the threads right, not IIS? When you do something like Task.Run(...) the task-scheduler will schedule your work on a thread-pool thread (32,768 pre-allocated at start-up). Of course you have to wait for the scheduler to give you one of the threads from the pool. Are you saying async doesn't need threads/TPL? I know it has some funky concurrency stuff that allows interleaved processing (rather than thread-pool processing), is this what you're referring to? Even IO would have to do something like this behind the scenes: Result IOMethod() { EventWaitHandle wait = new AutoResetEvent(false); // Do your IO - pass in the handle wait.WaitOne(); return result; } Wouldn't the pre-IO and post-IO need to be run via the scheduler if you want it to run asynchronously? The WaitOne will release the thread back to the pool. How is async any different?

UK-AL 11y ago

I use it to stop any long running io blocking my thread.

alimbada 11y ago

The async features are nice for when you need them, but just because the functionality exists doesn't mean you should use it all over the place (sounds like you aren't anyway :)). A good developer will know when/where to use async.

jayd16 11y ago

The style is great if you have a main thread you need to keep fast and responsive.

mhomde 11y ago

Async methods are mainly used in .Net apps that use an UI-thread paradigm since you avoid blocking the UI thread for things like IO calls

breischl 11y ago

Async is fantastic if you do a lot of I/O and you have to scale. For instance if you have a web service that makes a lot of network calls. In our particular case, and oversimplifying, the app is a smart router. Take a request, farm out pieces of it to multiple other servers, aggregate responses. Some of those requests finish in 5ms, some take several seconds, which is a crappy pattern to deal with. Today's not a particularly busy day, so we're doing about 70 req/sec/VM at 5% CPU on a dual core VM. In load tests I've had it up to 300 req/sec/VM with no problems. It actually bottlenecked our 10Gb network cards before the the CPU maxed out. I haven't tried running the actual app without async because it would be a major rewrite. But I did some benchmarking making lots of parallel HTTP calls with threads vs async, and found that async was 10-20x faster and used less CPU.

useerup 11y ago

> Out of interest, how many people here actually use async methods? Excluding being forced to by a library. We use it almost exclusively. Because of the new async/await syntax it is (almost) as easy to write and get correct as non-async code. Async/await makes an entire class of problems go away (and, ok, swaps it for a class of easier-to-solve problems). In a web application you always need to consider how your application will be impacted by the traffic. Are all of your requests served within 50 milliseconds? Fine, then you do not need async. Do your handlers ever call out to an external site or even a local database where it may block for more than 50 milliseconds? Then you need to consider what happens when almost all of the requests block at at same time: A colossal waste of resources. Traditionally we have handled this by increasing the number of threads we allow the server to use for serving requests. However, threads are expensive in overhead (memory, cpu for context switching) and it affects the footprint of your application, and with that how dense you can pack virtual servers. Enter async: When a request blocks on an external call (to an external site, database etc), the request relinquishes the thread which will be used to serve other requests. What's more: The more you use async/await, the more the application will auto-scale. It will only start new threads when there's actual work to be done rather than when there's waiting to be done.