async / await - czy awaitować wszystko?

async / await - czy awaitować wszystko?
KF
  • Rejestracja:prawie 5 lat
  • Ostatnio:ponad 4 lata
  • Postów:2
0

Jak jest lepiej:
Tak:

Kopiuj
        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ć:

Kopiuj
 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ć?
???

hzmzp
  • Rejestracja:ponad 11 lat
  • Ostatnio:dzień
  • Postów:625
2

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.

edytowany 1x, ostatnio: hzmzp
Patryk27
Moderator
  • Rejestracja:ponad 17 lat
  • Ostatnio:ponad rok
  • Lokalizacja:Wrocław
  • Postów:13042
0

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


edytowany 1x, ostatnio: Patryk27
SW
  • Rejestracja:około 5 lat
  • Ostatnio:4 miesiące
  • Postów:250
5
KF
  • Rejestracja:prawie 5 lat
  • Ostatnio:ponad 4 lata
  • Postów:2
0

@Patryk27: wydajności.

neves
  • Rejestracja:prawie 22 lata
  • Ostatnio:około 9 godzin
  • Lokalizacja:Kraków
  • Postów:1114
5

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.


edytowany 1x, ostatnio: neves
semicolon
  • Rejestracja:ponad 5 lat
  • Ostatnio:prawie 5 lat
  • Postów:114
0

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

edytowany 1x, ostatnio: semicolon
JU
  • Rejestracja:około 22 lata
  • Ostatnio:2 miesiące
  • Postów:5042
0

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.

SA
  • Rejestracja:ponad 12 lat
  • Ostatnio:około 10 godzin
  • Postów:1435
0
semicolon napisał(a):

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

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

semicolon
Równie dobrze mogłeś dać tam try ... catch i przepusić korutynę. Efekt ten sam. Następnym razem polecam doczytać do końca moją odpowiedź :-)
AF
  • Rejestracja:prawie 18 lat
  • Ostatnio:około 2 miesiące
5

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".

Aventus
Masz jakieś linki do tych dokumentów Microsoftu? Temat jest ciekawy a ja również spotykałem się przeważnie z rekomendacją że jeśli nie chcemy nic zrobić z wynikiem to nie ma sensu awaitować i wystarczy zwrócić task.
AF
Przez dawniej było inaczej miałem na myśli, że dawniej nie było na ten temat rekomendacji i zdanie środowiska było podzielone, ale raczej sugerowali nie awaitować. Na przykład Jiri sugeruje zwracać od razu https://www.tabsoverspaces.com/233659-do-not-await-what-does-not-need-to-be-awaited albo Stephen https://blog.stephencleary.com/2016/12/eliding-async-await.html mówi Do consider eliding when the method is just a passthrough.
AF
Szczególnie zdanie Stephena jest godne uwagi, bo to taki półbóg asynca, ma masę świetnych artykułów i dobrze ogarnia temat, a do tego jest autorem AsyncEx. Ale też trzeba pamiętać, że dużo się zmieniło od tamtego czasu, doszły ValueTaski, maszyna stanowa była przerabiana i optymalizowana, można teraz awaitować w większej liczbie miejsc, no i środowisko ma więcej doświadczenia z asynciem (często bardzo negatywnego).
Aventus
Dzięki, z chęcią poczytam.
WeiXiao
  • Rejestracja:około 9 lat
  • Ostatnio:około 8 godzin
  • Postów:5133
4

Szanowni interlokutorzy

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

xoxo

edytowany 1x, ostatnio: WeiXiao
SO
No już wczoraj czy tam kilka dni temu próbowałeś. Pytanie tylko po co :P
somekind
Wątek rozwiązany, można zamknąć. :P
kzkzg
Hmm, a któż to zaakceptował te odpowiedź, na pewno nie autor tematu..
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:7 dni
  • Lokalizacja:Wrocław
0

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

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.