czwartek, 10 sierpnia 2017

Nagroda: Do zwycięzcy wyślę ładnie zapakowane 0.7 Jack'a Daniels'a i dziesięć setek Wiśniówki Lubelskiej

Tematem konkursu jest zoptymalizowanie procesu zamiany ciągu bajtów na obiekty.

Szczegóły na temat konkursu wraz z przykładowym kodem znajdują się na moim GitHub, gdzie zapraszam: https://github.com/TeoVincent/TEO-KONKURS
Poprzez socket z centrali telekomunikacyjnej przychodzi ciąg bajtów, który zawiera informacje o tym jakie zdarzenia wystąpiły w tej centrali. Chodzi o to aby w jak najbardziej optymalny sposób (jak najszybciej) zamienić te bajty na obiekty.
Do mierzenia wydajności wykorzystujemy BenchmarkDotNet, który jest dołączony i odpowiednio skonfigurowany w projekcie.
Projekt zawiera już kilka wersji z moimi próbami optymalizacji. Podjąłem nawet próbę zarządzania pamięcią na własną rękę ale próba ta spaliła na panewkach. Osiągnąłem bardzo małe zużycie pamięci ale nie przełożyło się to na szybkość obliczeń. Czuję jednak, że da się jeszcze to lepiej zoptymalizować. Na tą chwilę nie wiem jak. Na każdego, któremu uda się poprawić wydajność, oprócz nagród rzeczowych, spadnie szacunek ludzi naszej społeczności.
Projekt zawiera zestaw testów jednostkowych, które pilnują czy kolejne coraz to bardziej optymalne wersje nadal poprawnie wykonują parsowanie.

Zasady wygranej

Wygrywa ten kto napisze najszybszą wersję parsowania. Konkurs trwa do 31-12-2018 do 23:59:59.999. Wersja uznana jest za najszybszą jeśli od poprzedniej najszybszej wersji będzie szybsza o 3% w każdym z 10 powtórzeń testu.
Nagroda zwycięscy zostaje przyznana jeśli po pull request'cie z najszybszą wersją przez kolejne 30 dni nikt nie nadeśle szybszej wersji wówczas.

Motywacja

Niedawno natrafiłem na projekt BenchmarkDotNet, który mnie zachwycił. Chcąc się nim pobawić wymyślałem sobie pretekst do tych zabaw - tym pretekstem jest właśnie temat tego konkursu.
Napisałem kilka wersji parsera eksperymentując z kodem. Robiłem niewielkie zmiany i odpalałem testy po czym sprawdzałem czy wydajność się poprawiła czy spadła. Nadal jednak jestem przekonany, że można osiągnąć większą wydajność, ale mi się już pomysły skończyły.
Śledząc kolejne wersje tych parserów będziecie mogli zobaczyć na żywo, na konkretnym przypadku:
  • jak bardzo nie wydajny jest regex
  • czy i o ile jest szybszy switch od if
  • jakie metody linq są wolne i jak bardzo potrafią być wolne
  • czy StringBuilder naprawdę jest szybszy od zwykłego string
  • zarządzanie pamięcią na własną rękę tak aby GC miał jak najmniej pracy
  • czy try {} catch {} ma wpływ na wydajność.
Będziecie mogli również zobaczyć jak się konfiguruje i odpala BenchmarkDotNet oraz podejście do testów jednostkowych, które testują wszystkie wersje bibliotek parsera w jednym teście.
Na każdego, któremu uda się poprawić wydajność, oprócz nagród rzeczowych, spadnie szacunek ludzi naszej społeczności, a ja z pewnością nauczę się czegoś nowego.
Obecny poziom wydajności dla projektu produkcyjnego już dawno jest zadowalający. Tutaj dalsze optymalizacji mają charakter rozrywki.

0 komentarze :

Prześlij komentarz