Je\u015bli masz wra\u017cenie, \u017ce krytyczny fragment kodu dzia\u0142a \u201etroch\u0119 za wolno\u201d, ten artyku\u0142 jest dla ciebie. Poka\u017c\u0119 na realnym przyk\u0142adzie z produkcji, jak optymalizacja kodu pozwoli\u0142a zej\u015b\u0107 z 10 do 3 maszyn w Azure – bez zmiany funkcjonalno\u015bci aplikacji. Zamiast teoretyzowa\u0107, przejdziemy przez konkretne techniki optymalizacji wydajno\u015bci kodu C#, kt\u00f3re mo\u017cesz od razu zastosowa\u0107 w swoim projekcie opartym o framework .NET. <\/p>\n\n\n\n
Dowiesz si\u0119: <\/p>\n\n\n\n
<\/p>\n
Powodem powstania tego tekstu jest ch\u0119\u0107 podzielenia si\u0119 do\u015bwiadczeniem z optymalizacji kodu zdobytym podczas pracy nad prawdziw\u0105 aplikacj\u0105 w chmurze. Dwa lata temu by\u0142em cz\u0142onkiem zespo\u0142u, kt\u00f3ry mia\u0142 za zadanie programowa\u0107 system hostowany na platformie Microsoft Azure. System, zbudowany w oparciu o Azure Functions i .NET 7, przetwarza\u0142 strumie\u0144 zdarze\u0144 JSON: parsowanie, walidacja, budowa modeli – wszystko w czasie zbli\u017conym do rzeczywistego. Wym\u00f3g biznesowy by\u0142 prosty, ale wymagaj\u0105cy obliczeniowo: wydajno\u015b\u0107 aplikacji na poziomie 2000 zdarze\u0144 na sekund\u0119. <\/p>\n\n\n\n
Pierwsze\u00a0testy wydajno\u015bci<\/a>\u00a0pokaza\u0142y brutaln\u0105 prawd\u0119 – przy domy\u015blnej implementacji potrzebowali\u015bmy a\u017c 10 maszyn w dedykowanym planie\u00a0Azure. Po serii\u00a0mikrooptymalizacji\u00a0i ponownej analizie wydajno\u015bci okaza\u0142o si\u0119, \u017ce ten sam ruch obs\u0142u\u017cymy przy pomocy 3 maszyn o identycznych parametrach. To nie by\u0142a magia czy zas\u0142uga intuicji. To by\u0142 efekt \u015bwiadomego podej\u015bcia do zarz\u0105dzania pami\u0119ci\u0105, doboru algorytm\u00f3w, pracy na strukturach danych i mierzenia czasu wykonania.\u00a0<\/p>\n\n\n\n Kod \u017ar\u00f3d\u0142owy przyk\u0142ad\u00f3w, benchmarki i wyniki dotycz\u0105ce wydajno\u015bci znajdziesz w repozytorium GitHub<\/a>. Istotn\u0105 kwesti\u0105 jest to, \u017ce optymalizacja kodu pod wzgl\u0119dem czasu wykonania lub zu\u017cycia pami\u0119ci ma sens tylko wtedy, gdy jak\u0105\u015b operacj\u0119 wykonujemy znacz\u0105c\u0105 ilo\u015b\u0107 razy w stosunkowo kr\u00f3tkim czasie i zale\u017cy nam na jak najkr\u00f3tszym czasie wykonania zadania przy jak najmniejszej konsumpcji zasob\u00f3w. <\/p>\n\n\n\n Generalnie tylko w tym przypadku nale\u017cy wykonywa\u0107 optymalizacj\u0119, gdy\u017c jednym z wa\u017cnych czynnik\u00f3w jest to, \u017ce kod po takiej optymalizacji jest zazwyczaj du\u017co mniej czytelny i trudniejszy do zrozumienia. <\/p>\n\n\n\n Do identyfikacji takich obszar\u00f3w kodu mo\u017cna u\u017cy\u0107 narz\u0119dzia typu profiler np. https:\/\/www.jetbrains.com\/dotmemory<\/a>, https:\/\/www.jetbrains.com\/profiler<\/a> lub narz\u0119dzi dostarczanych z Visual Studio. Maj\u0105c zidentyfikowane takie fragmenty kodu, mo\u017cna przyst\u0105pi\u0107 do optymalizacji. <\/p>\n\n\n\n Optymalizacja polega na pr\u00f3bie napisania kodu realizuj\u0105cego t\u0119 sam\u0105 funkcjonalno\u015b\u0107 w spos\u00f3b bardziej wydajny i por\u00f3wnaniu obydwu implementacji pod wzgl\u0119dem czasu wykonania i zu\u017cycia pami\u0119ci. <\/p>\n\n\n\n Narz\u0119dziem, kt\u00f3re staje si\u0119 de facto standardem, je\u015bli chodzi o pomiar wydajno\u015bci kodu przy przeprowadzaniu mikrooptymalizacji na platformie .NET, jest BenchmarkDotNet<\/a> – jest to narz\u0119dzie, kt\u00f3rego Microsoft wewn\u0119trznie u\u017cywa do monitoringu wydajno\u015bci podczas tworzenia samej platformy .NET. Narz\u0119dzie to jest wpi\u0119te w proces CI, kt\u00f3re monitoruje, czy okre\u015blone fragmenty kodu nie s\u0105 mniej wydajne po wprowadzonych zmianach. Je\u015bli wydajno\u015b\u0107 kodu si\u0119 pogarsza, wtedy zmiany w takim kodzie s\u0105 ponownie sprawdzane. <\/p>\n\n\n\n Idealnie by\u0142oby te\u017c, gdyby testy by\u0142y przeprowadzane na dok\u0142adnie takiej samej maszynie, na jakiej uruchamiany jest kod produkcyjnie – tzn. chodzi o model procesora, ilo\u015b\u0107 pami\u0119ci i system operacyjny. W przesz\u0142o\u015bci zdarza\u0142o si\u0119, \u017ce dana optymalizacja poprawia\u0142a wydajno\u015b\u0107 na danym \u015brodowisku, ale pogarsza\u0142a na innym – generalnie takie sytuacje s\u0105 stosunkowo rzadkie. <\/p>\n\n\n\n W przypadku ka\u017cdego testu b\u0119dzie prezentowana tabela z wynikami – w przedstawionych rezultatach test\u00f3w najbardziej b\u0119d\u0105 istotne kolumny Mean <\/strong>oznaczaj\u0105ce czas wykonania i Allocated <\/strong>oznaczaj\u0105ce zu\u017cycie pami\u0119ci. <\/p>\n\n\n\n Podsumowuj\u0105c – w praktyce warto optymalizowa\u0107, gdy: <\/p>\n\n\n\n W innych przypadkach lepiej skupi\u0107 si\u0119 na czytelno\u015bci kodu i jako\u015bci projektu <\/p>\n\n\n\n Jak ju\u017c wcze\u015bniej wspomnia\u0142em, artyku\u0142 rozpatruje dwa typy optymalizacji. W pierwszym celem jest skr\u00f3cenie czasu wykonania, a w drugim – zmniejszenie konsumpcji pami\u0119ci. <\/p>\n\n\n\n W wielu przypadkach optymalizacja zu\u017cycia pami\u0119ci przynosi znacznie bardziej spektakularne rezultaty (po\u015brednio te\u017c wp\u0142ywaj\u0105c na czas wykonania), gdy\u017c pami\u0119\u0107 jest \u0142atwo zaalokowa\u0107, ale proces zwalniania pami\u0119ci ze sterty jest du\u017co bardziej skomplikowany. Wi\u0119cej o dzia\u0142aniu mechanizmu Garbage Collector mo\u017cna znale\u017a\u0107 pod tym adresem https:\/\/www.youtube.com\/watch?v=BeuNvhd1L_g<\/a>. <\/p>\n\n\n\n Logowanie (logging) mo\u017ce znacz\u0105co wp\u0142yn\u0105\u0107 na konsumpcj\u0119 zasob\u00f3w, zw\u0142aszcza gdy jest wykonywane setki tysi\u0119cy razy. Szczeg\u00f3\u0142owe wyniki benchmark\u00f3w dla tego scenariusza zosta\u0142y opublikowane w raporcie B01 Logging \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>, do kt\u00f3rego b\u0119dziemy si\u0119 odnosi\u0107 w dalszej cz\u0119\u015bci sekcji.<\/p>\n\n\n\n Przy por\u00f3wnywaniu wynik\u00f3w\u00a0<\/strong>wida\u0107, \u017ce gdy mamy w\u0142\u0105czony poziom logowania i fizycznie logujemy wiadomo\u015bci, to zu\u017cycie pami\u0119ci i czasy wykonania s\u0105 bardzo podobne (testy zaczynaj\u0105ce si\u0119 od\u00a0 Wi\u0119cej informacji:\u00a0https:\/\/learn.microsoft.com\/en-us\/dotnet\/core\/extensions\/logger-message-generator<\/a>. Najgorsze wyniki otrzymujemy w przypadku wykorzystania\u00a0mechanizmu string interpolacji ( Dodatkowo, gdy mamy na poziomie projektu ( Wywo\u0142ywanie metod R\u00f3\u017cnice s\u0105 wyra\u017anie widoczne w zestawieniu czasu wykonania oraz alokacji pami\u0119ci<\/strong> pomi\u0119dzy podej\u015bciem standardowym a wersj\u0105 generowan\u0105 ( \u0141atw\u0105 alternatyw\u0105 w przypadku metody W przypadku wyra\u017ce\u0144 lambda sposobem na popraw\u0119 wydajno\u015bci jest unikanie closures<\/em> (wi\u0119cej o closures<\/em> w artykule C# in Depth<\/a>) poprzez przekazywanie zewn\u0119trznego stanu do \u015brodka funkcji lambda jako parametr.<\/p>\n\n\n\n Na podstawie testu ( Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y opisane w raporcie B03 Closures \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n To dobry przyk\u0142ad na to, jak drobna zmiana stylu pisania kodu mo\u017ce pom\u00f3c w optymalizacji kodu bez wi\u0119kszej utraty jego czytelno\u015bci.<\/p>\n\n\n\n U\u017cycie obiekt\u00f3w typu span<\/em> (wi\u0119cej o span<\/em> w artykule C# \u2013 All About Span: Exploring a New .NET Mainstay<\/a>) znacz\u0105co przy\u015bpiesza dzia\u0142anie kodu, redukuj\u0105c potrzeb\u0119 dodatkowych alokacji pami\u0119ci. Jest on szczeg\u00f3lnie przydatny we wszelkiego rodzaju parserach, kt\u00f3re wyci\u0105gaj\u0105 dane z istniej\u0105cego obiektu, tworz\u0105c wirtualne okno w pami\u0119ci w przetwarzanym obiekcie, zapobiegaj\u0105c tym samym nowym alokacjom.<\/p>\n\n\n\n Obydwa testy realizuj\u0105 identyczn\u0105 funkcjonalno\u015b\u0107, przetwarzaj\u0105c tekst na list\u0119 z warto\u015bciami typu liczbowego. Jak wida\u0107, test Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B04 Spans \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n Je\u015bli twoja aplikacja intensywnie parsuje tekst (np. logi, CSV, payloady z API), to u\u017cycie span\u00f3w mo\u017ce znacz\u0105co wp\u0142yn\u0105\u0107 na popraw\u0119 wydajno\u015bci.<\/p>\n\n\n\n W benchmarkach: <\/p>\n\n\n\n To ju\u017c\u00a0dotyczy\u00a0zaawansowanych technik, ale w\u00a0parserach, systemach na\u00a0edge<\/a>\u00a0(np.\u00a0IoT, funkcje\u00a0serverless) i us\u0142ugach API r\u00f3\u017cnica bywa kolosalna.\u00a0<\/p>\n\n\n\n Kolejnym przyk\u0142adem jest kod, kt\u00f3ry np. sprawdza bie\u017c\u0105c\u0105 warto\u015b\u0107 na podstawie niezmiennej listy warto\u015bci. Gdy ta lista jest niezmienna, warto zadeklarowa\u0107 j\u0105 na poziomie klasy jako pole statyczne i zamiast za ka\u017cdym razem tworzy\u0107 now\u0105 list\u0119, przekazywa\u0107 t\u0119 zadeklarowan\u0105 instancj\u0119 do wywo\u0142ania funkcji sprawdzaj\u0105cej.<\/p>\n\n\n\n Jak wida\u0107, test Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B05 Static \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n Przy dodawaniu element\u00f3w do obiektu typu generyczna lista dobrym zaleceniem jest ustawienie docelowego rozmiaru listy (je\u015bli znamy albo w przybli\u017ceniu jeste\u015bmy w stanie okre\u015bli\u0107 docelowy rozmiar listy). Ustawienie to wp\u0142ywa na to, \u017ce wewn\u0119trznie tablica, kt\u00f3ra przechowuje elementy, nie jest wielokrotnie realokowana i kod dzia\u0142a zauwa\u017calnie szybciej ( Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B06 Capacity \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n To jedna z tych drobnych zmian, kt\u00f3re w intensywnych strukturach danych (np. listy obiekt\u00f3w DTO) robi\u0105 du\u017c\u0105 r\u00f3\u017cnic\u0119.<\/p>\n\n\n\n Nast\u0119pnym przyk\u0142adem jest sytuacja, w kt\u00f3rej wyszukujemy elementy po okre\u015blonych unikalnych kluczach. Je\u015bli dane, na kt\u00f3rych wyszukujemy, s\u0105 niezmienne lub wielokrotnie przeprowadzamy wyszukiwanie na tych samych danych, to op\u0142aca si\u0119 zamiast u\u017cywa\u0107 LINQ ( Natomiast w sytuacji, gdy s\u0142ownik musi zosta\u0107 najpierw utworzony ( Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B07 LINQ vs Dictionary \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n Je\u017celi dane, np. z bazy danych, s\u0105 \u0142adowane rzadko, a odczyty s\u0105 bardzo cz\u0119ste, to jest to idealny kandydat na zoptymalizowany kod z wykorzystaniem s\u0142ownika.<\/p>\n\n\n\n W pewnych przypadkach sposobem na optymalizacj\u0119 jest implementacja kodu za pomoc\u0105 obiektu typu warto\u015bciowego zamiast\u00a0obiektu referencyjnego<\/a>\u00a0( Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B08 Interface vs Implementation \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n Czasem zastosowanie\u00a0 W przeciwnym razie przeci\u0105\u017cenie mentalne i ryzyko napisania b\u0142\u0119dnych konstrukcji jest wi\u0119ksze ni\u017c korzy\u015bci. <\/p>\n\n\n\n Kolejn\u0105 istotn\u0105 rzecz\u0105 w przypadku pracy z klas\u0105 typu generyczna lista jest efektywno\u015b\u0107 dodawania lub usuwania element\u00f3w z listy.<\/p>\n\n\n\n Jest to szczeg\u00f3lnie wa\u017cne, gdy programista dodaje lub usuwa zbi\u00f3r element\u00f3w na pocz\u0105tku listy. Wida\u0107 wyra\u017anie, \u017ce dodawanie ( Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B09 List Manipulations \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n Tworz\u0105c kod, kt\u00f3ry intensywnie operuje na ma\u0142ych tablicach, warto rozwa\u017cy\u0107 alokowanie element\u00f3w tej tablicy na stosie zamiast na stercie.<\/p>\n\n\n\n Warto u\u017cy\u0107 wyra\u017cenia W tym konkretnym przyk\u0142adzie zosta\u0142a dwukrotnie zaimplementowana metoda wyliczaj\u0105ca hash z zawarto\u015bci obiektu \u2014 osobno dla ma\u0142ego i du\u017cego obiektu. Pierwsza implementacja jest klasyczna ( Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B10 StackAlloc & ArrayPool \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n W przyk\u0142adach: <\/p>\n\n\n\n To \u015bwietny przyk\u0142ad, jak \u015bwiadome zarz\u0105dzanie tablicami mo\u017ce odci\u0105\u017cy\u0107 zar\u00f3wno CPU, jak i GC. <\/p>\n\n\n\n Je\u017celi chodzi o kod, kt\u00f3ry przeprowadza np. walidacj\u0119 danych wprowadzanych przez u\u017cytkownika, mamy dwa sposoby przekazywania u\u017cytkownikowi informacji, \u017ce wprowadzone dane nie s\u0105 zgodne z okre\u015blonymi regu\u0142ami. Pierwszym sposobem jest rzucanie wyj\u0105tk\u00f3w, a drugim zastosowanie wzorca result<\/em>, w kt\u00f3rym przekazujemy informacj\u0119 o potencjalnych problemach. Por\u00f3wnuj\u0105c test Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B11 Throwing Exceptions \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n W przypadku serializacji i deserializacji JSON przy u\u017cyciu Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B12 Serialization \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n W przypadku wyszukiwania w s\u0142owniku mo\u017cna skorzysta\u0107 z mechanizmu Dictionary alternate lookup<\/em>, umo\u017cliwiaj\u0105cego przeszukiwanie s\u0142ownika przy u\u017cyciu klucza innego typu ni\u017c ten, z kt\u00f3rym zosta\u0142 on pierwotnie utworzony. Jest to mo\u017cliwe dzi\u0119ki strukturze Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B13 Dictionary Alternate Lookup \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n W przypadku definiowania nowych obiekt\u00f3w typu warto\u015bciowego zalecanym sposobem definiowania tego typu obiekt\u00f3w jest korzystanie z konstrukcji Szczeg\u00f3\u0142owe wyniki benchmarku zosta\u0142y przedstawione w raporcie B14 Structs \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\n W przypadku przetwarzania du\u017cych zbior\u00f3w danych zamiast klasycznego przetwarzania wszystkich danych w pami\u0119ci warto rozwa\u017cy\u0107 zastosowanie obiekt\u00f3w typu stream<\/em> oraz
https:\/\/github.com\/tomekjanicki\/Performance<\/a> – ka\u017cdy benchmark w osobnym katalogu projektu Performance. Mo\u017cesz je samodzielnie uruchomi\u0107, aby sprawdzi\u0107 zachowanie na swojej maszynie, komend\u0105: <\/p>\n\n\n\ndotnet run -c Release --project .\\Performance\\Performance.csproj -- --memory true <\/pre>\n\n\n\n
Kiedy i jak przeprowadza\u0107 optymalizacj\u0119 kodu?<\/strong> <\/h2>\n\n\n\n
\n
Typy optymalizacji<\/strong> <\/h2>\n\n\n\n
B01 Logging – kiedy logi zabijaj\u0105 wydajno\u015b\u0107 aplikacji<\/strong> <\/h2>\n\n\n\n
LogInformationLevelEnabled<\/code>). Najwi\u0119ksze r\u00f3\u017cnice wida\u0107, gdy\u00a0wywo\u0142amy\u00a0metody loguj\u0105ce, ale poziom logowania nie jest w\u0142\u0105czony (testy zaczynaj\u0105ce si\u0119 od\u00a0LogDebugLevelNotEnabled<\/code>). Wtedy najlepsze wyniki osi\u0105gamy, u\u017cywaj\u0105c trybu generowania kodu (LogDebugLevelNotEnabledSourceGenerated<\/code>).\u00a0\u00a0<\/p>\n\n\n\nLogDebugLevelNotEnabledStringInterpolation<\/code>) – ze wzgl\u0119du na natur\u0119 obiektu string, kt\u00f3ry jest niezmienny, za ka\u017cdym razem generujemy nowy string i alokujemy pami\u0119\u0107, nawet gdy w rzeczywisto\u015bci nic nie logujemy.\u00a0\u00a0<\/p>\n\n\n\nPerformance.csproj<\/code>) ustawiony poziom analizy kodu kompilatora na \u201elatest-recommended\u201d, to kompilator generuje ostrze\u017cenia CA1848:\u00a0Use\u00a0the\u00a0LoggerMessage\u00a0delegates\u00a0i CA2254:\u00a0Template\u00a0should\u00a0be a\u00a0static\u00a0expression. Wi\u0119cej o CA2254 mo\u017cna znale\u017a\u0107 pod tym adresem\u00a0https:\/\/www.youtube.com\/watch?v=6zoMd_FwSwQ<\/a>\u00a0<\/p>\n\n\n\nB02 Enums i generatory: szybsze TryParse \/ ToString<\/strong> <\/h2>\n\n\n\n
TryParse<\/code> oraz ToString<\/code> na obiektach typu wyliczeniowego wi\u0105\u017ce si\u0119 z u\u017cyciem refleksji, co ma bezpo\u015bredni wp\u0142yw na czas wykonania<\/strong> i zu\u017cycie pami\u0119ci. Zast\u0119puj\u0105c te metody alternatywnymi implementacjami opartymi o generowanie kodu<\/strong>, mo\u017cna znacz\u0105co poprawi\u0107 wydajno\u015b\u0107 \u2014 jednym z takich rozwi\u0105za\u0144 jest biblioteka Supernova.Enum.Generators<\/a>.<\/p>\n\n\n\nStandard<\/code> vs SourceGenerated<\/code>), co zosta\u0142o szczeg\u00f3\u0142owo pokazane w raporcie B02 Enums \u2013 pe\u0142ne wyniki benchmark\u00f3w<\/a>.<\/p>\n\n\n\nToString<\/code> jest zbudowanie przy starcie aplikacji statycznego s\u0142ownika i pobieranie warto\u015bci tekstowej na postawie warto\u015bci enum<\/code>. <\/p>\n\n\n\nB03 Closures: ukryty wr\u00f3g w lambdach<\/strong> <\/h2>\n\n\n\n
ExecuteWithoutClosure<\/code>) wida\u0107, \u017ce nast\u0119puje znacz\u0105ce skr\u00f3cenie czasu wykonania oraz nie wyst\u0119puje alokacja pami\u0119ci.<\/p>\n\n\n\nB04 Spans <T>: przyspieszenie parser\u00f3w i praca \u201ena kraw\u0119dzi\u201d pami\u0119ci<\/strong> <\/h2>\n\n\n\n
GetResultSpan<\/code> jest znacz\u0105co szybszy i alokuje mniej pami\u0119ci w por\u00f3wnaniu do testu GetResultClassic<\/code>.<\/p>\n\n\n\n\n
B05 Static – pola statyczne zamiast ci\u0105g\u0142ego tworzenia kolekcji<\/strong> <\/h2>\n\n\n\n
GetValidValuesStatic<\/code> znacz\u0105co obni\u017ca czas wykonania i zu\u017cycie pami\u0119ci w por\u00f3wnaniu do GetValidValuesNotStatic<\/code>.<\/p>\n\n\n\nB06 Capacity – jak jedna linijka mo\u017ce znacznie poprawi\u0107 szybko\u015b\u0107 listy<\/strong> <\/h2>\n\n\n\n
ProcessWithCapacity<\/code> vs ProcessWithoutCapacity<\/code>).<\/p>\n\n\n\nB07 Linq vs Dictionary i FrozenDictionary<\/strong><\/h2>\n\n\n\n
GetUsersByIdsLinq<\/code>) zbudowa\u0107 s\u0142ownik i przeprowadza\u0107 wyszukiwanie w tym s\u0142owniku (GetUsersByIdsAlreadyBuiltDictionary<\/code>).<\/p>\n\n\n\nGetUsersByIdsBuildDictionary<\/code>), operacja ta jest znacznie bardziej czasoch\u0142onna i alokuje wi\u0119cej pami\u0119ci. Dodatkowo do por\u00f3wnania zosta\u0142 do\u0142\u0105czony niedawno wprowadzony typ Frozen Dictionary<\/em> (wi\u0119cej informacji w dokumentacji FrozenDictionary \u2013 Microsoft Learn<\/a>), kt\u00f3ry \u2014 jak wida\u0107 \u2014 konsumuje jeszcze wi\u0119cej zasob\u00f3w podczas budowy (GetUsersByIdsBuildFrozenDictionary<\/code>), ale jest minimalnie szybszy przy odczycie (GetUsersByIdsAlreadyBuiltFrozenDictionary<\/code>).<\/p>\n\n\n\nB08 Interface vs Implementation<\/strong> <\/h2>\n\n\n\n
GetStructResultDirectly<\/code>) – dzi\u0119ki temu zabiegowi mo\u017cemy w pewnych sytuacjach zminimalizowa\u0107 dodatkowe alokacje pami\u0119ci. Jednak nale\u017cy zwr\u00f3ci\u0107 uwag\u0119, \u017ce nie nale\u017cy tego obiektu przekazywa\u0107 jako interfejs (GetStructResultAsInterface<\/code>)\u00a0(gdy\u017c wymusza to operacj\u0119 boxing<\/em>). W przypadku klasy nie ma to praktycznie \u017cadnego znaczenia.\u00a0<\/p>\n\n\n\nrecord\u00a0struct<\/code>\u00a0zamiast klasy pozwala eliminowa\u0107 cz\u0119\u015b\u0107 alokacji.\u00a0Warunek:\u00a0<\/p>\n\n\n\n\n
B09 List Manipulations zakresy zamiast pojedynczych operacji<\/strong> <\/h2>\n\n\n\n
InsertItemsAtTheBeginningOneByOne<\/code>) lub usuwanie (RemoveItemsAtTheBeginningOneByOne<\/code>) element\u00f3w pojedynczo jest najmniej efektywne \u2014 zwi\u0105zane jest to z wielokrotn\u0105 realokacj\u0105 wewn\u0119trznej tablicy obiektu typu list. Warto wtedy skorzysta\u0107 z metod operuj\u0105cych na zakresach (InsertItemsAtTheBeginningByRange<\/code>, RemoveItemsAtTheBeginningByRange<\/code>) lub zbudowa\u0107 ca\u0142kowicie now\u0105 list\u0119, korzystaj\u0105c z LINQ (RemoveItemsAtTheBeginningByLinq<\/code>).<\/p>\n\n\n\nB10 Stack Alloc Array Pool – zarz\u0105dzanie pami\u0119ci\u0105 dla wymagaj\u0105cych<\/strong> <\/h2>\n\n\n\n
stackalloc<\/code> (wi\u0119cej informacji w dokumentacji stackalloc \u2013 Microsoft Learn<\/a>), maj\u0105c na uwadze ograniczenia stosu. W przypadku gdy potrzebujemy u\u017cy\u0107 tablicy o wi\u0119kszym rozmiarze, mo\u017cna skorzysta\u0107 z obiektu ArrayPool<\/code> (zob. ArrayPool<T> \u2013 Microsoft Learn<\/a>), kt\u00f3ry minimalizuje nowe alokacje pami\u0119ci, reu\u017cywaj\u0105c ju\u017c zaalokowan\u0105 pami\u0119\u0107.<\/p>\n\n\n\nExecuteHashCalculatorWithClassicSmallData<\/code>, ExecuteHashCalculatorWithClassicLargeData<\/code>), a druga wykorzystuje stackalloc<\/code> i array pool (ExecuteHashCalculatorWithStackAllocOrArrayPoolSmallData<\/code>, ExecuteHashCalculatorWithStackAllocOrArrayPoolLargeData<\/code>). Jak wida\u0107, zoptymalizowane metody konsumuj\u0105 du\u017co mniej pami\u0119ci i dzia\u0142aj\u0105 szybciej lub por\u00f3wnywalnie z klasyczn\u0105 implementacj\u0105.<\/p>\n\n\n\n\n
B11 Throwing Exceptions<\/strong> <\/h2>\n\n\n\n
CreateUserWithResult<\/code> z CreateUserWithException<\/code>, wida\u0107 spory narzut czasowy oraz alokacji pami\u0119ci w przypadku tego drugiego.<\/p>\n\n\n\nB12 Serialization JSON: UTF8, nie string<\/strong> <\/h2>\n\n\n\n
System.Text.Json<\/code> warto bazowa\u0107 bezpo\u015brednio na danych binarnych kodowanych do formatu UTF8, na kt\u00f3rym opiera si\u0119 komunikacja sieciowa (SerializeDirectlyToUtf8<\/code>, DeserializeDirectlyFromUtf8<\/code>), z pomini\u0119ciem transkodowania do obiektu typu string<\/code> (SerializeToStringToUtf8<\/code>, DeserializeFromUtf8FromString<\/code>), kt\u00f3ry przechowuje dane w formacie UTF16. Por\u00f3wnuj\u0105c poni\u017csze testy, wida\u0107 znacz\u0105ce r\u00f3\u017cnice w zu\u017cyciu pami\u0119ci.<\/p>\n\n\n\nB13 Dictionary Alternate Lookup<\/strong> <\/h2>\n\n\n\n
AlternateLookup<\/code>, kt\u00f3ra u\u017cywa klasy IAlternateEqualityComparer<\/code> do por\u00f3wnywania r\u00f3\u017cnych typ\u00f3w kluczy, co pozwala na popraw\u0119 wydajno\u015bci \u2014 na przyk\u0142ad wyszukiwanie danych za pomoc\u0105 klasy ReadOnlySpan<char><\/code> (CountWords2<\/code>) zamiast przydzielania nowego ci\u0105gu znak\u00f3w (CountWords1<\/code>). W tym przyk\u0142adzie wida\u0107 ogromne r\u00f3\u017cnice w konsumpcji pami\u0119ci.<\/p>\n\n\n\nB14 Structs<\/strong> <\/h2>\n\n\n\n
record struct<\/code> zamiast struct<\/code>. Ten pierwszy ma generowane przez kompilator metody GetHashCode<\/code> i ToString<\/code>. Standardowy struct<\/code> u\u017cywa refleksji do implementacji tych metod, kt\u00f3ra jest du\u017co mniej efektywna. Jest to szczeg\u00f3lnie wa\u017cne, je\u017celi tak zdefiniowanej struktury u\u017cywamy jako klucza w s\u0142owniku lub korzystamy z obiektu typu HashSet<\/code>. Metoda GetDictionaryKeyAsRecordStruct<\/code> dzia\u0142a du\u017co efektywniej ni\u017c GetDictionaryKeyAsStruct<\/code>.<\/p>\n\n\n\nB15 Streams<\/strong> <\/h2>\n\n\n\n
I(Async)Enumerable<\/code>. Zaprezentowany przyk\u0142ad realizuje funkcjonalno\u015b\u0107 czytania z pliku ka\u017cdego wiersza, zamiany go na obiekt, wyliczenia warto\u015bci \u015bredniej i zapisania wyliczonej warto\u015bci \u015bredniej wraz z oryginalnymi warto\u015bciami w pliku wynikowym.<\/p>\n\n\n\n