async / await - czy awaitować wszystko?

Jak jest lepiej:
Tak:

        private async Task<string> Dawaj()
        {
            var wynik = await new HttpClient().GetStringAsync("www.google.pl");
            return wynik;
        }

        private async Task<string> Wyzej()
        {
            var wynik = await Dawaj();
            return wynik.Remove(5);
        }

Czy nie robić pierwszej metody asyncowej i nie awaitować:

 private Task<string> Dawaj()
        {
            var wynik = new HttpClient().GetStringAsync("www.google.pl");
            return wynik;
        }

Innymi słowy, czy jeżeli w metodzie nie potrzebujemy nic robić w wynikiem tylko przekazać go wyżej, to czy jest sens tam awaitować?
???

Zależy co z tym później robisz/jaki ma to wpływ na dalszą część aplikacji.
Choć podejrzewam, że to będzie to pierwsze.

lepiej pod jakim względem:
Liczby linijek?
Liczby literek?
Czytelności?
Złożoności?
Czasu kompilacji?

Jeśli zwracasz Task, to nie awaituj.
http://foreverframe.net/czy-async-await-w-one-linerach-ma-sens/

@Patryk27: wydajności.

Tutaj masz opisany ten dylemat:

Prefer async/await over directly returning Task

co ogólnie można sprowadzić do tego, że jeśli naprawdę przejmujesz się wydajnością danego fragmentu kodu to lepiej jest zwrócić taska, jeśli nie (w większości wypadków) to lepiej robić async/await all the way i tak istnieje spora szansa że ten fragment kodu zostanie zinlinowany i dodatkowa maszyna stanów nie zostanie wygenerowana.

Jeśli chodzi o await/async to bez znaczenia. Pierwsza opcja oznacza, że będziesz robił o jedno przerwanie więcej. Równie dobrze mógłbyś napisać Dawaj bez składni await, ponieważ wołając GetStringAsync i tak uzyskasz korutynę. Używanie await ma sens jeśli czekasz na wartość, lub błąd z nią związany i gdy chcesz to obsłużyć. W przeciwnym razie lepiej jest przepuścić wykonanie.

A jeśli chodzi o sam podział metod to dopóki obie są prywatne to podziały nie mają większego znaczenia, także luz :-)

Generalnie wszędzie piszą, że async/await "rozmnaża się" po całym kodzie. Wynika z tego, że jeśli gdzieś tam w jednym miejscu zrobisz metodę asynchroniczną, to w całym wywołaniu też powinieneś pododawać te async/await. Przy czym "powinieneś" nie oznacza, że "koniecznie musisz". To wszystko zależy od kontekstu.

semicolon napisał(a):

Jeśli chodzi o await/async to bez znaczenia.

Dowód, że ma znaczenie: https://dotnetfiddle.net/1ACDwX

Różnic jest bardzo dużo:

• Zrobienie metody async pakuje wszystko w maszynę stanów + try + catch, więc jak poleci wyjątek, to będzie złapany do Taska
• await gubi wyjątki zagnieżdżone w drzewie Tasków
• await łapie SynchronizationContext (można to zmienić oczywiście), przez co może zmienić zachowanie wątku (i na przykład spowodować deadlock)
• async dokłada maszynę stanów, która sama w sobie ma niezerowy koszt (czasowy i pamięciowy)
• async zmienia zachowanie bloków try i finally

Rozważania można kontynuować o inne typy tasków, dalsze problemy z wielowątkowością itp. Ja bym dał await, tak teraz zalecają dokumenty od MS (dawniej było inaczej), a jak już martwimy się o wydajność, to jest masa innych spraw, które trzeba rozważyć, więc wtedy pytanie zmienia się w "które rozwiązanie spełnia wszystkie nasze wymagania".

Szanowni interlokutorzy

chciałbym ogłosić że dnia dzisiejszego postanowiłem wrzucić ten wątek na sam szczyt

xoxo

Szanowny interlokutorze.
Oczekujesz, że coś się zmieniło w tej kwestii przez ostatnie 2 lata?