Using async await pattern from static method when concurrency isn't needed
Is there a benefit to using the async/await pattern when you are running things in a synchronous manner?
For instance in my app I have static methods that are called by cron (hangfire) to do various IO bound tasks. A simple contrived example is this:
static void Run(string args)
var data = Test(args);
//..do stuff with returned data
public static List<string> Test(string args)
return Db.Select(args);
Is there any advantage to writing this code like so:
static void Run(string args)
var dataTask = await TestAsync(args);
dataTask.Wait();
//..do stuff with returned data
public static async Task<List<string>> TestAsync(string args)
return await Db.SelectAsync(args);
My colleague tells me that I should always use this pattern and use async methods if they are available as it adds under the hood optimization but he is unable to explain why that is and I can't really find any clear cut explanation.
If I write my code with this type of pattern in my static methods it ends up looking like:
var data = someMethod();
data.Wait();
var data2 = someOtherMethod(data);
data2.Wait();
I understand using async await pattern when firing up lots of concurrent tasks but when the code originates from a static method and has to run in order like this is there any benefit at all? Which way should I write it?
c# async-await
add a comment |
Is there a benefit to using the async/await pattern when you are running things in a synchronous manner?
For instance in my app I have static methods that are called by cron (hangfire) to do various IO bound tasks. A simple contrived example is this:
static void Run(string args)
var data = Test(args);
//..do stuff with returned data
public static List<string> Test(string args)
return Db.Select(args);
Is there any advantage to writing this code like so:
static void Run(string args)
var dataTask = await TestAsync(args);
dataTask.Wait();
//..do stuff with returned data
public static async Task<List<string>> TestAsync(string args)
return await Db.SelectAsync(args);
My colleague tells me that I should always use this pattern and use async methods if they are available as it adds under the hood optimization but he is unable to explain why that is and I can't really find any clear cut explanation.
If I write my code with this type of pattern in my static methods it ends up looking like:
var data = someMethod();
data.Wait();
var data2 = someOtherMethod(data);
data2.Wait();
I understand using async await pattern when firing up lots of concurrent tasks but when the code originates from a static method and has to run in order like this is there any benefit at all? Which way should I write it?
c# async-await
1
Are you really combiningawait
andWait()
in production code? If so, why?
– Peter Bons
Nov 10 '18 at 19:21
oops edited it. Thanks
– Guerrilla
Nov 10 '18 at 19:45
add a comment |
Is there a benefit to using the async/await pattern when you are running things in a synchronous manner?
For instance in my app I have static methods that are called by cron (hangfire) to do various IO bound tasks. A simple contrived example is this:
static void Run(string args)
var data = Test(args);
//..do stuff with returned data
public static List<string> Test(string args)
return Db.Select(args);
Is there any advantage to writing this code like so:
static void Run(string args)
var dataTask = await TestAsync(args);
dataTask.Wait();
//..do stuff with returned data
public static async Task<List<string>> TestAsync(string args)
return await Db.SelectAsync(args);
My colleague tells me that I should always use this pattern and use async methods if they are available as it adds under the hood optimization but he is unable to explain why that is and I can't really find any clear cut explanation.
If I write my code with this type of pattern in my static methods it ends up looking like:
var data = someMethod();
data.Wait();
var data2 = someOtherMethod(data);
data2.Wait();
I understand using async await pattern when firing up lots of concurrent tasks but when the code originates from a static method and has to run in order like this is there any benefit at all? Which way should I write it?
c# async-await
Is there a benefit to using the async/await pattern when you are running things in a synchronous manner?
For instance in my app I have static methods that are called by cron (hangfire) to do various IO bound tasks. A simple contrived example is this:
static void Run(string args)
var data = Test(args);
//..do stuff with returned data
public static List<string> Test(string args)
return Db.Select(args);
Is there any advantage to writing this code like so:
static void Run(string args)
var dataTask = await TestAsync(args);
dataTask.Wait();
//..do stuff with returned data
public static async Task<List<string>> TestAsync(string args)
return await Db.SelectAsync(args);
My colleague tells me that I should always use this pattern and use async methods if they are available as it adds under the hood optimization but he is unable to explain why that is and I can't really find any clear cut explanation.
If I write my code with this type of pattern in my static methods it ends up looking like:
var data = someMethod();
data.Wait();
var data2 = someOtherMethod(data);
data2.Wait();
I understand using async await pattern when firing up lots of concurrent tasks but when the code originates from a static method and has to run in order like this is there any benefit at all? Which way should I write it?
c# async-await
c# async-await
edited Nov 10 '18 at 19:45
Guerrilla
asked Nov 10 '18 at 19:01
GuerrillaGuerrilla
2,84263481
2,84263481
1
Are you really combiningawait
andWait()
in production code? If so, why?
– Peter Bons
Nov 10 '18 at 19:21
oops edited it. Thanks
– Guerrilla
Nov 10 '18 at 19:45
add a comment |
1
Are you really combiningawait
andWait()
in production code? If so, why?
– Peter Bons
Nov 10 '18 at 19:21
oops edited it. Thanks
– Guerrilla
Nov 10 '18 at 19:45
1
1
Are you really combining
await
and Wait()
in production code? If so, why?– Peter Bons
Nov 10 '18 at 19:21
Are you really combining
await
and Wait()
in production code? If so, why?– Peter Bons
Nov 10 '18 at 19:21
oops edited it. Thanks
– Guerrilla
Nov 10 '18 at 19:45
oops edited it. Thanks
– Guerrilla
Nov 10 '18 at 19:45
add a comment |
1 Answer
1
active
oldest
votes
as it adds under the hood optimization but he is unable to explain why that is
It is amazing to me how many people believe that async is always the best choice yet they cannot say why. This is a big misunderstanding in the community. Unfortunately, Microsoft is kind of pushing this notion. I believe they are doing this to simplify guidance.
Async IO helps with two things: 1) save threads 2) make GUI apps easier by doing away with thread management.
Most applications are totally unconstrained by the number of threads that are running. For those apps, async IO adds zero throughput, it costs additional CPU and complicates the code. I know, because I have measured throughput and scalability. I have worked on many applications.
In particular, the IO itself does not become faster. The only thing that changes is the way the call is initiated and completed. There are no IO optimizations here whatsoever.
Use async when it is either convenient to you or you have evidence that the number of running threads will be a problem. Do not use it by default because productivity will be lower. There are additional ways to add bugs. Tooling is worse, the code is longer, debugging and profiling is harder.
Of course, there is nothing wrong with using it if it is the right tool for the job.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53242405%2fusing-async-await-pattern-from-static-method-when-concurrency-isnt-needed%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
as it adds under the hood optimization but he is unable to explain why that is
It is amazing to me how many people believe that async is always the best choice yet they cannot say why. This is a big misunderstanding in the community. Unfortunately, Microsoft is kind of pushing this notion. I believe they are doing this to simplify guidance.
Async IO helps with two things: 1) save threads 2) make GUI apps easier by doing away with thread management.
Most applications are totally unconstrained by the number of threads that are running. For those apps, async IO adds zero throughput, it costs additional CPU and complicates the code. I know, because I have measured throughput and scalability. I have worked on many applications.
In particular, the IO itself does not become faster. The only thing that changes is the way the call is initiated and completed. There are no IO optimizations here whatsoever.
Use async when it is either convenient to you or you have evidence that the number of running threads will be a problem. Do not use it by default because productivity will be lower. There are additional ways to add bugs. Tooling is worse, the code is longer, debugging and profiling is harder.
Of course, there is nothing wrong with using it if it is the right tool for the job.
add a comment |
as it adds under the hood optimization but he is unable to explain why that is
It is amazing to me how many people believe that async is always the best choice yet they cannot say why. This is a big misunderstanding in the community. Unfortunately, Microsoft is kind of pushing this notion. I believe they are doing this to simplify guidance.
Async IO helps with two things: 1) save threads 2) make GUI apps easier by doing away with thread management.
Most applications are totally unconstrained by the number of threads that are running. For those apps, async IO adds zero throughput, it costs additional CPU and complicates the code. I know, because I have measured throughput and scalability. I have worked on many applications.
In particular, the IO itself does not become faster. The only thing that changes is the way the call is initiated and completed. There are no IO optimizations here whatsoever.
Use async when it is either convenient to you or you have evidence that the number of running threads will be a problem. Do not use it by default because productivity will be lower. There are additional ways to add bugs. Tooling is worse, the code is longer, debugging and profiling is harder.
Of course, there is nothing wrong with using it if it is the right tool for the job.
add a comment |
as it adds under the hood optimization but he is unable to explain why that is
It is amazing to me how many people believe that async is always the best choice yet they cannot say why. This is a big misunderstanding in the community. Unfortunately, Microsoft is kind of pushing this notion. I believe they are doing this to simplify guidance.
Async IO helps with two things: 1) save threads 2) make GUI apps easier by doing away with thread management.
Most applications are totally unconstrained by the number of threads that are running. For those apps, async IO adds zero throughput, it costs additional CPU and complicates the code. I know, because I have measured throughput and scalability. I have worked on many applications.
In particular, the IO itself does not become faster. The only thing that changes is the way the call is initiated and completed. There are no IO optimizations here whatsoever.
Use async when it is either convenient to you or you have evidence that the number of running threads will be a problem. Do not use it by default because productivity will be lower. There are additional ways to add bugs. Tooling is worse, the code is longer, debugging and profiling is harder.
Of course, there is nothing wrong with using it if it is the right tool for the job.
as it adds under the hood optimization but he is unable to explain why that is
It is amazing to me how many people believe that async is always the best choice yet they cannot say why. This is a big misunderstanding in the community. Unfortunately, Microsoft is kind of pushing this notion. I believe they are doing this to simplify guidance.
Async IO helps with two things: 1) save threads 2) make GUI apps easier by doing away with thread management.
Most applications are totally unconstrained by the number of threads that are running. For those apps, async IO adds zero throughput, it costs additional CPU and complicates the code. I know, because I have measured throughput and scalability. I have worked on many applications.
In particular, the IO itself does not become faster. The only thing that changes is the way the call is initiated and completed. There are no IO optimizations here whatsoever.
Use async when it is either convenient to you or you have evidence that the number of running threads will be a problem. Do not use it by default because productivity will be lower. There are additional ways to add bugs. Tooling is worse, the code is longer, debugging and profiling is harder.
Of course, there is nothing wrong with using it if it is the right tool for the job.
edited Nov 10 '18 at 19:19
answered Nov 10 '18 at 19:14
usrusr
144k26186299
144k26186299
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53242405%2fusing-async-await-pattern-from-static-method-when-concurrency-isnt-needed%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Are you really combining
await
andWait()
in production code? If so, why?– Peter Bons
Nov 10 '18 at 19:21
oops edited it. Thanks
– Guerrilla
Nov 10 '18 at 19:45