Optymalizacja kodu C# w .NET – techniki poprawy wydajności kodu aplikacji 

Jeśli masz wrażenie, że krytyczny fragment kodu działa „trochę za wolno”, ten artykuł jest dla ciebie. Pokażę na realnym przykładzie z produkcji, jak optymalizacja kodu pozwoliła zejść z 10 do 3 maszyn w Azure – bez zmiany funkcjonalności aplikacji. Zamiast teoretyzować, przejdziemy przez konkretne techniki optymalizacji wydajności kodu C#, które możesz od razu zastosować w swoim projekcie opartym o framework .NET. 

Dowiesz się: 

• kiedy warto optymalizować 
• jak mierzyć wydajność kodu 
• jak dobrać algorytm i struktury danych, aby zwiększyć wydajność aplikacji, 
• a także jak robić to w sposób, który nie zabija całkowicie czytelności kodu. 

Wprowadzenie: od 10 do 3 maszyn: realna historia optymalizacji kodu

Powodem powstania tego tekstu jest chęć podzielenia się doświadczeniem z optymalizacji kodu zdobytym podczas pracy nad prawdziwą aplikacją w chmurze. Dwa lata temu byłem członkiem zespołu, który miał za zadanie programować system hostowany na platformie Microsoft Azure. System, zbudowany w oparciu o Azure Functions i .NET 7, przetwarzał strumień zdarzeń JSON: parsowanie, walidacja, budowa modeli – wszystko w czasie zbliżonym do rzeczywistego. Wymóg biznesowy był prosty, ale wymagający obliczeniowo: wydajność aplikacji na poziomie 2000 zdarzeń na sekundę. 

Pierwsze testy wydajności pokazały brutalną prawdę – przy domyślnej implementacji potrzebowaliśmy aż 10 maszyn w dedykowanym planie Azure. Po serii mikrooptymalizacji i ponownej analizie wydajności okazało się, że ten sam ruch obsłużymy przy pomocy 3 maszyn o identycznych parametrach. To nie była magia czy zasługa intuicji. To był efekt świadomego podejścia do zarządzania pamięcią, doboru algorytmów, pracy na strukturach danych i mierzenia czasu wykonania. 

Kod źródłowy przykładów, benchmarki i wyniki dotyczące wydajności znajdziesz w repozytorium GitHub. 
https://github.com/tomekjanicki/Performance – każdy benchmark w osobnym katalogu projektu Performance. Możesz je samodzielnie uruchomić, aby sprawdzić zachowanie na swojej maszynie, komendą: 

dotnet run -c Release --project .\Performance\Performance.csproj -- --memory true 

Kiedy i jak przeprowadzać optymalizację kodu? 

Istotną kwestią jest to, że optymalizacja kodu pod względem czasu wykonania lub zużycia pamięci ma sens tylko wtedy, gdy jakąś operację wykonujemy znaczącą ilość razy w stosunkowo krótkim czasie i zależy nam na jak najkrótszym czasie wykonania zadania przy jak najmniejszej konsumpcji zasobów.  

Generalnie tylko w tym przypadku należy wykonywać optymalizację, gdyż jednym z ważnych czynników jest to, że kod po takiej optymalizacji jest zazwyczaj dużo mniej czytelny i trudniejszy do zrozumienia.  

Do identyfikacji takich obszarów kodu można użyć narzędzia typu profiler np. https://www.jetbrains.com/dotmemory, https://www.jetbrains.com/profiler lub narzędzi dostarczanych z Visual Studio. Mając zidentyfikowane takie fragmenty kodu, można przystąpić do optymalizacji.  

Optymalizacja polega na próbie napisania kodu realizującego tę samą funkcjonalność w sposób bardziej wydajny i porównaniu obydwu implementacji pod względem czasu wykonania i zużycia pamięci.  

Narzędziem, które staje się de facto standardem, jeśli chodzi o pomiar wydajności kodu przy przeprowadzaniu mikrooptymalizacji na platformie .NET, jest BenchmarkDotNet – jest to narzędzie, którego Microsoft wewnętrznie używa do monitoringu wydajności podczas tworzenia samej platformy .NET. Narzędzie to jest wpięte w proces CI, które monitoruje, czy określone fragmenty kodu nie są mniej wydajne po wprowadzonych zmianach. Jeśli wydajność kodu się pogarsza, wtedy zmiany w takim kodzie są ponownie sprawdzane.  

Idealnie byłoby też, gdyby testy były przeprowadzane na dokładnie takiej samej maszynie, na jakiej uruchamiany jest kod produkcyjnie – tzn. chodzi o model procesora, ilość pamięci i system operacyjny. W przeszłości zdarzało się, że dana optymalizacja poprawiała wydajność na danym środowisku, ale pogarszała na innym – generalnie takie sytuacje są stosunkowo rzadkie.  

W przypadku każdego testu będzie prezentowana tabela z wynikami – w przedstawionych rezultatach testów najbardziej będą istotne kolumny Mean oznaczające czas wykonania i Allocated oznaczające zużycie pamięci.  

Podsumowując – w praktyce warto optymalizować, gdy: 

• ten sam algorytm wykonujesz setki tysięcy lub miliony razy, 
• fragment jest w krytycznym hot-path (np. wewnątrz wąskiej pętli przetwarzania), 
• dotyczy intensywnej komunikacji z bazy danych, API albo serwer musi utrzymać bardzo dużą liczbę zapytań, 
• czujesz, że szybkość i efektywność są kluczowe dla doświadczenia użytkownika (np. czas ładowania ekranu, responsywność panelu). 

W innych przypadkach lepiej skupić się na czytelności kodu i jakości projektu 

Typy optymalizacji 

Jak już wcześniej wspomniałem, artykuł rozpatruje dwa typy optymalizacji. W pierwszym celem jest skrócenie czasu wykonania, a w drugim – zmniejszenie konsumpcji pamięci.  

W wielu przypadkach optymalizacja zużycia pamięci przynosi znacznie bardziej spektakularne rezultaty (pośrednio też wpływając na czas wykonania), gdyż pamięć jest łatwo zaalokować, ale proces zwalniania pamięci ze sterty jest dużo bardziej skomplikowany. Więcej o działaniu mechanizmu Garbage Collector można znaleźć pod tym adresem https://www.youtube.com/watch?v=BeuNvhd1L_g. 

B01 Logging – kiedy logi zabijają wydajność aplikacji 

Logowanie (logging) może znacząco wpłynąć na konsumpcję zasobów, zwłaszcza gdy jest wykonywane setki tysięcy razy. Szczegółowe wyniki benchmarków dla tego scenariusza zostały opublikowane w raporcie B01 Logging – pełne wyniki benchmarków, do którego będziemy się odnosić w dalszej części sekcji.

Przy porównywaniu wyników widać, że gdy mamy włączony poziom logowania i fizycznie logujemy wiadomości, to zużycie pamięci i czasy wykonania są bardzo podobne (testy zaczynające się od LogInformationLevelEnabled). Największe różnice widać, gdy wywołamy metody logujące, ale poziom logowania nie jest włączony (testy zaczynające się od LogDebugLevelNotEnabled). Wtedy najlepsze wyniki osiągamy, używając trybu generowania kodu (LogDebugLevelNotEnabledSourceGenerated).  

Więcej informacji: https://learn.microsoft.com/en-us/dotnet/core/extensions/logger-message-generator. Najgorsze wyniki otrzymujemy w przypadku wykorzystania mechanizmu string interpolacji (LogDebugLevelNotEnabledStringInterpolation) – ze względu na naturę obiektu string, który jest niezmienny, za każdym razem generujemy nowy string i alokujemy pamięć, nawet gdy w rzeczywistości nic nie logujemy.  

Dodatkowo, gdy mamy na poziomie projektu (Performance.csproj) ustawiony poziom analizy kodu kompilatora na „latest-recommended”, to kompilator generuje ostrzeżenia CA1848: Use the LoggerMessage delegates i CA2254: Template should be a static expression. Więcej o CA2254 można znaleźć pod tym adresem https://www.youtube.com/watch?v=6zoMd_FwSwQ 

B02 Enums i generatory: szybsze TryParse / ToString 

Wywoływanie metod TryParse oraz ToString na obiektach typu wyliczeniowego wiąże się z użyciem refleksji, co ma bezpośredni wpływ na czas wykonania i zużycie pamięci. Zastępując te metody alternatywnymi implementacjami opartymi o generowanie kodu, można znacząco poprawić wydajność — jednym z takich rozwiązań jest biblioteka Supernova.Enum.Generators.

Różnice są wyraźnie widoczne w zestawieniu czasu wykonania oraz alokacji pamięci pomiędzy podejściem standardowym a wersją generowaną (Standard vs SourceGenerated), co zostało szczegółowo pokazane w raporcie B02 Enums – pełne wyniki benchmarków.

Łatwą alternatywą w przypadku metody ToString jest zbudowanie przy starcie aplikacji statycznego słownika i pobieranie wartości tekstowej na postawie wartości enum. 

B03 Closures: ukryty wróg w lambdach 

W przypadku wyrażeń lambda sposobem na poprawę wydajności jest unikanie closures (więcej o closures w artykule C# in Depth) poprzez przekazywanie zewnętrznego stanu do środka funkcji lambda jako parametr.

Na podstawie testu (ExecuteWithoutClosure) widać, że następuje znaczące skrócenie czasu wykonania oraz nie występuje alokacja pamięci.

Szczegółowe wyniki benchmarku zostały opisane w raporcie B03 Closures – pełne wyniki benchmarków.

To dobry przykład na to, jak drobna zmiana stylu pisania kodu może pomóc w optymalizacji kodu bez większej utraty jego czytelności.

B04 Spans <T>: przyspieszenie parserów i praca „na krawędzi” pamięci 

Użycie obiektów typu span (więcej o span w artykule C# – All About Span: Exploring a New .NET Mainstay) znacząco przyśpiesza działanie kodu, redukując potrzebę dodatkowych alokacji pamięci. Jest on szczególnie przydatny we wszelkiego rodzaju parserach, które wyciągają dane z istniejącego obiektu, tworząc wirtualne okno w pamięci w przetwarzanym obiekcie, zapobiegając tym samym nowym alokacjom.

Obydwa testy realizują identyczną funkcjonalność, przetwarzając tekst na listę z wartościami typu liczbowego. Jak widać, test GetResultSpan jest znacząco szybszy i alokuje mniej pamięci w porównaniu do testu GetResultClassic.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B04 Spans – pełne wyniki benchmarków.

Jeśli twoja aplikacja intensywnie parsuje tekst (np. logi, CSV, payloady z API), to użycie spanów może znacząco wpłynąć na poprawę wydajności.

W benchmarkach: 

• klasyczna implementacja alokuje nowe tablice/stringi, 
• implementacja ze spanami jest znacząco szybsza i zużywa mniej pamięci. 

To już dotyczy zaawansowanych technik, ale w parserach, systemach na edge (np. IoT, funkcje serverless) i usługach API różnica bywa kolosalna. 

B05 Static – pola statyczne zamiast ciągłego tworzenia kolekcji 

Kolejnym przykładem jest kod, który np. sprawdza bieżącą wartość na podstawie niezmiennej listy wartości. Gdy ta lista jest niezmienna, warto zadeklarować ją na poziomie klasy jako pole statyczne i zamiast za każdym razem tworzyć nową listę, przekazywać tę zadeklarowaną instancję do wywołania funkcji sprawdzającej.

Jak widać, test GetValidValuesStatic znacząco obniża czas wykonania i zużycie pamięci w porównaniu do GetValidValuesNotStatic.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B05 Static – pełne wyniki benchmarków.

B06 Capacity – jak jedna linijka może znacznie poprawić szybkość listy 

Przy dodawaniu elementów do obiektu typu generyczna lista dobrym zaleceniem jest ustawienie docelowego rozmiaru listy (jeśli znamy albo w przybliżeniu jesteśmy w stanie określić docelowy rozmiar listy). Ustawienie to wpływa na to, że wewnętrznie tablica, która przechowuje elementy, nie jest wielokrotnie realokowana i kod działa zauważalnie szybciej (ProcessWithCapacity vs ProcessWithoutCapacity).

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B06 Capacity – pełne wyniki benchmarków.

To jedna z tych drobnych zmian, które w intensywnych strukturach danych (np. listy obiektów DTO) robią dużą różnicę.

B07 Linq vs Dictionary i FrozenDictionary

Następnym przykładem jest sytuacja, w której wyszukujemy elementy po określonych unikalnych kluczach. Jeśli dane, na których wyszukujemy, są niezmienne lub wielokrotnie przeprowadzamy wyszukiwanie na tych samych danych, to opłaca się zamiast używać LINQ (GetUsersByIdsLinq) zbudować słownik i przeprowadzać wyszukiwanie w tym słowniku (GetUsersByIdsAlreadyBuiltDictionary).

Natomiast w sytuacji, gdy słownik musi zostać najpierw utworzony (GetUsersByIdsBuildDictionary), operacja ta jest znacznie bardziej czasochłonna i alokuje więcej pamięci. Dodatkowo do porównania został dołączony niedawno wprowadzony typ Frozen Dictionary (więcej informacji w dokumentacji FrozenDictionary – Microsoft Learn), który — jak widać — konsumuje jeszcze więcej zasobów podczas budowy (GetUsersByIdsBuildFrozenDictionary), ale jest minimalnie szybszy przy odczycie (GetUsersByIdsAlreadyBuiltFrozenDictionary).

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B07 LINQ vs Dictionary – pełne wyniki benchmarków.

Jeżeli dane, np. z bazy danych, są ładowane rzadko, a odczyty są bardzo częste, to jest to idealny kandydat na zoptymalizowany kod z wykorzystaniem słownika.

B08 Interface vs Implementation 

W pewnych przypadkach sposobem na optymalizację jest implementacja kodu za pomocą obiektu typu wartościowego zamiast obiektu referencyjnego (GetStructResultDirectly) – dzięki temu zabiegowi możemy w pewnych sytuacjach zminimalizować dodatkowe alokacje pamięci. Jednak należy zwrócić uwagę, że nie należy tego obiektu przekazywać jako interfejs (GetStructResultAsInterface) (gdyż wymusza to operację boxing). W przypadku klasy nie ma to praktycznie żadnego znaczenia. 

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B08 Interface vs Implementation – pełne wyniki benchmarków.

Czasem zastosowanie record struct zamiast klasy pozwala eliminować część alokacji. Warunek: 

• nie przekazujesz struktury jako interfejsu (boxing zwiększa koszt), 
• struktura jest używana w algorytmie intensywnie przeliczającym dane. 

W przeciwnym razie przeciążenie mentalne i ryzyko napisania błędnych konstrukcji jest większe niż korzyści. 

B09 List Manipulations zakresy zamiast pojedynczych operacji 

Kolejną istotną rzeczą w przypadku pracy z klasą typu generyczna lista jest efektywność dodawania lub usuwania elementów z listy.

Jest to szczególnie ważne, gdy programista dodaje lub usuwa zbiór elementów na początku listy. Widać wyraźnie, że dodawanie (InsertItemsAtTheBeginningOneByOne) lub usuwanie (RemoveItemsAtTheBeginningOneByOne) elementów pojedynczo jest najmniej efektywne — związane jest to z wielokrotną realokacją wewnętrznej tablicy obiektu typu list. Warto wtedy skorzystać z metod operujących na zakresach (InsertItemsAtTheBeginningByRange, RemoveItemsAtTheBeginningByRange) lub zbudować całkowicie nową listę, korzystając z LINQ (RemoveItemsAtTheBeginningByLinq).

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B09 List Manipulations – pełne wyniki benchmarków.

B10 Stack Alloc Array Pool – zarządzanie pamięcią dla wymagających 

Tworząc kod, który intensywnie operuje na małych tablicach, warto rozważyć alokowanie elementów tej tablicy na stosie zamiast na stercie.

Warto użyć wyrażenia stackalloc (więcej informacji w dokumentacji stackalloc – Microsoft Learn), mając na uwadze ograniczenia stosu. W przypadku gdy potrzebujemy użyć tablicy o większym rozmiarze, można skorzystać z obiektu ArrayPool (zob. ArrayPool<T> – Microsoft Learn), który minimalizuje nowe alokacje pamięci, reużywając już zaalokowaną pamięć.

W tym konkretnym przykładzie została dwukrotnie zaimplementowana metoda wyliczająca hash z zawartości obiektu — osobno dla małego i dużego obiektu. Pierwsza implementacja jest klasyczna (ExecuteHashCalculatorWithClassicSmallData, ExecuteHashCalculatorWithClassicLargeData), a druga wykorzystuje stackalloc i array pool (ExecuteHashCalculatorWithStackAllocOrArrayPoolSmallData, ExecuteHashCalculatorWithStackAllocOrArrayPoolLargeData). Jak widać, zoptymalizowane metody konsumują dużo mniej pamięci i działają szybciej lub porównywalnie z klasyczną implementacją.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B10 StackAlloc & ArrayPool – pełne wyniki benchmarków.

W przykładach: 

• klasyczny kod – alokuje nowe tablice przy każdym wywołaniu, 
• wersja ze stackalloc i ArrayPool – znacząco redukuje zużycia pamięci przy zachowaniu wysokiej szybkości działania. 

To świetny przykład, jak świadome zarządzanie tablicami może odciążyć zarówno CPU, jak i GC. 

B11 Throwing Exceptions 

Jeżeli chodzi o kod, który przeprowadza np. walidację danych wprowadzanych przez użytkownika, mamy dwa sposoby przekazywania użytkownikowi informacji, że wprowadzone dane nie są zgodne z określonymi regułami. Pierwszym sposobem jest rzucanie wyjątków, a drugim zastosowanie wzorca result, w którym przekazujemy informację o potencjalnych problemach. Porównując test CreateUserWithResult z CreateUserWithException, widać spory narzut czasowy oraz alokacji pamięci w przypadku tego drugiego.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B11 Throwing Exceptions – pełne wyniki benchmarków.

B12 Serialization JSON: UTF8, nie string 

W przypadku serializacji i deserializacji JSON przy użyciu System.Text.Json warto bazować bezpośrednio na danych binarnych kodowanych do formatu UTF8, na którym opiera się komunikacja sieciowa (SerializeDirectlyToUtf8, DeserializeDirectlyFromUtf8), z pominięciem transkodowania do obiektu typu string (SerializeToStringToUtf8, DeserializeFromUtf8FromString), który przechowuje dane w formacie UTF16. Porównując poniższe testy, widać znaczące różnice w zużyciu pamięci.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B12 Serialization – pełne wyniki benchmarków.

B13 Dictionary Alternate Lookup 

W przypadku wyszukiwania w słowniku można skorzystać z mechanizmu Dictionary alternate lookup, umożliwiającego przeszukiwanie słownika przy użyciu klucza innego typu niż ten, z którym został on pierwotnie utworzony. Jest to możliwe dzięki strukturze AlternateLookup, która używa klasy IAlternateEqualityComparer do porównywania różnych typów kluczy, co pozwala na poprawę wydajności — na przykład wyszukiwanie danych za pomocą klasy ReadOnlySpan<char> (CountWords2) zamiast przydzielania nowego ciągu znaków (CountWords1). W tym przykładzie widać ogromne różnice w konsumpcji pamięci.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B13 Dictionary Alternate Lookup – pełne wyniki benchmarków.

B14 Structs 

W przypadku definiowania nowych obiektów typu wartościowego zalecanym sposobem definiowania tego typu obiektów jest korzystanie z konstrukcji record struct zamiast struct. Ten pierwszy ma generowane przez kompilator metody GetHashCode i ToString. Standardowy struct używa refleksji do implementacji tych metod, która jest dużo mniej efektywna. Jest to szczególnie ważne, jeżeli tak zdefiniowanej struktury używamy jako klucza w słowniku lub korzystamy z obiektu typu HashSet. Metoda GetDictionaryKeyAsRecordStruct działa dużo efektywniej niż GetDictionaryKeyAsStruct.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B14 Structs – pełne wyniki benchmarków.

B15 Streams 

W przypadku przetwarzania dużych zbiorów danych zamiast klasycznego przetwarzania wszystkich danych w pamięci warto rozważyć zastosowanie obiektów typu stream oraz I(Async)Enumerable. Zaprezentowany przykład realizuje funkcjonalność czytania z pliku każdego wiersza, zamiany go na obiekt, wyliczenia wartości średniej i zapisania wyliczonej wartości średniej wraz z oryginalnymi wartościami w pliku wynikowym.

W pierwszej implementacji (AsyncProcessingGetRowsWriteRows) wszystkie wiersze źródłowe są wczytywane do pamięci, a następnie cała kolekcja wiersz po wierszu zapisywana jest w pliku wynikowym. W drugiej implementacji (AsyncStreamProcessingReWrite) naraz pobierany jest tylko jeden wiersz, wykonywane są obliczenia na tym wierszu, a wynik zapisywany jest bezpośrednio w pliku wynikowym. Z porównania wyników widać, że pierwsza implementacja jest minimalnie szybsza, ale zużywa dużo więcej pamięci.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B15 Streams – pełne wyniki benchmarków.

Jeśli twój system pracuje na dużych plikach, logach lub danych z bazy danych, strumieniowe przetwarzanie pozwoli utrzymać stabilną wydajność twoich aplikacji, nawet gdy wolumen danych rośnie.

Ogólne zasady – jak pisać wydajny kod, który nadal da się utrzymać 

Na koniec kilka zasad, które warto zapamiętać, jeśli chcesz zwiększyć wydajność aplikacji, ale nadal spać spokojnie: 

• Zaczynaj od algorytmu. Dobry algorytm i odpowiednie struktury danych często dają więcej niż lokalne mikrooptymalizacje. 
• Mierz, nie zgaduj. Używaj narzędzi – Visual Studio, BenchmarkDotNet, logów – aby mierzyć realne problemy. 
• Myśl o całości – od bazy po UI. To, jak kod „rozmawia” z bazą danych, jak obsługuje API, jak działa po stronie serwera i jak zarządza pamięcią, ma wpływ na całe doświadczenie użytkownika. 
• Korzystaj z pomocy społeczności i dokumentacji. Dokumentacja Microsoft, kursy Microsoft Learn, repozytoria GitHub i przykłady kodu innych zespołów to świetne dodatkowe zasoby, które mogą pokazać ci gotowe techniki optymalizacji. 
• Pamiętaj o użytkowniku. Dla biznesu liczy się krótszy czas odpowiedzi, mniejsze koszty utrzymania, mniej maszyn, stabilność działania. Techniczne detale służą temu, by dowieźć lepszą wydajność i realne korzyści. 

Dobrze zaprojektowany, wydajny i efektywny kod C# nie musi być „magiczny” i niezrozumiały. Można łączyć pragmatyzm z jakością – tak, aby zwiększyć wydajność aplikacji tam, gdzie to naprawdę ma znaczenie, a jednocześnie zachować sensowną czytelność dla kolejnych osób, które będą ten kod rozwijać i programować w nim nowe funkcje. 

FAQ