Using async await pattern from static method when concurrency isn't needed










1















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?










share|improve this question



















  • 1





    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















1















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?










share|improve this question



















  • 1





    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













1












1








1








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 10 '18 at 19:45







Guerrilla

















asked Nov 10 '18 at 19:01









GuerrillaGuerrilla

2,84263481




2,84263481







  • 1





    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












  • 1





    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







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












1 Answer
1






active

oldest

votes


















3















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.






share|improve this answer
























    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
    );



    );













    draft saved

    draft discarded


















    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









    3















    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.






    share|improve this answer





























      3















      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.






      share|improve this answer



























        3












        3








        3








        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.






        share|improve this answer
















        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 10 '18 at 19:19

























        answered Nov 10 '18 at 19:14









        usrusr

        144k26186299




        144k26186299



























            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

            Crossroads (UK TV series)

            ữḛḳṊẴ ẋ,Ẩṙ,ỹḛẪẠứụỿṞṦ,Ṉẍừ,ứ Ị,Ḵ,ṏ ṇỪḎḰṰọửḊ ṾḨḮữẑỶṑỗḮṣṉẃ Ữẩụ,ṓ,ḹẕḪḫỞṿḭ ỒṱṨẁṋṜ ḅẈ ṉ ứṀḱṑỒḵ,ḏ,ḊḖỹẊ Ẻḷổ,ṥ ẔḲẪụḣể Ṱ ḭỏựẶ Ồ Ṩ,ẂḿṡḾồ ỗṗṡịṞẤḵṽẃ ṸḒẄẘ,ủẞẵṦṟầṓế