Benchmarking small code samples in C#, can this implementation be improved?

Finalizacja nie musi być zakończona przed powrotem GC.Collect. Finalizacja jest kolejkowana, a następnie uruchamiana w osobnym wątku. Ten wątek może być nadal aktywny podczas testów, wpływając na wyniki.

Jeśli chcesz upewnić się, że zakończenie zostało zakończone przed rozpoczęciem testów, możesz zadzwonić GC.WaitForPendingFinalizers, która będzie blokowana do czasu wyczyszczenia kolejki finalizacji:

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

Jeśli chcesz usunąć interakcje GC z równania, możesz uruchomić wywołanie "rozgrzewki" po GC.Nie wcześniej. W ten sposób wiesz, że. NET będzie już mieć wystarczająco dużo pamięci przydzielonej z systemu operacyjnego dla zestawu roboczego funkcji.

Pamiętaj, że dla każdej iteracji wykonujesz wywołanie metody nieinlinowanej, więc upewnij się, że porównujesz rzeczy, które testujesz do pustego ciała. Będziesz musiał również zaakceptować, że można tylko niezawodnie czas rzeczy, które są kilkakrotnie dłuższe niż wywołanie metody.

Ponadto, w zależności od tego, jakiego rodzaju rzeczy profilujesz, możesz chcieć biegać w oparciu o czas przez pewien czas, a nie przez określoną liczbę iteracji-może to prowadzić do łatwiejszych porównywalnych liczb bez konieczności bardzo krótkiego biegu dla najlepszej implementacji i/lub bardzo długiego dla najgorszej.

W ogóle bym nie zdała delegata:

1. wywołanie delegata to ~ virtual method call. Nie tani: ~ 25% najmniejszej alokacji pamięci w .NET. jeśli interesują Cię szczegóły, zobacz np. ten link .
2. anonimowi delegaci mogą prowadzić do użycia zamknięć, których nawet nie zauważysz. Ponownie, dostęp do pól zamknięcia jest zauważalny niż np. dostęp do zmiennej na stosie.

Przykładowy kod prowadzący do zamknięcia:

public void Test()
{
  int someNumber = 1;
  Profiler.Profile("Closure access", 1000000, 
    () => someNumber + someNumber);
}

Jeśli nie wiesz o zamknięciach, spójrz na tę metodę w. NET Reflector.

Myślę, że najtrudniejszym problemem do przezwyciężenia z takich metod benchmarkingu jest rozliczanie przypadków krawędzi i nieoczekiwane. Na przykład - " jak działają dwa urywki kodu przy dużym obciążeniu procesora / wykorzystaniu sieci/dyskietce / itp."Są świetne do podstawowych testów logicznych, aby sprawdzić, czy dany algorytm działa znacznie szybciej niż inny. Ale aby poprawnie przetestować większość wydajności kodu, trzeba by stworzyć test, który mierzy konkretne wąskie gardła tego konkretnego kodu.

Nadal powiedziałbym, że testowanie małych bloków kodu często ma niewielki zwrot z inwestycji i może zachęcić do używania zbyt skomplikowanego kodu zamiast prostego kodu do konserwacji. Pisanie jasnego kodu, który inni programiści, lub ja 6 miesięcy w dół linii, mogą szybko zrozumieć, będzie miało więcej korzyści wydajności niż wysoce zoptymalizowany kod.

Dzwoniłbym kilka razy na rozgrzewkę, nie tylko jedną.

Sugestie dotyczące poprawy

1. Wykrywanie, czy środowisko wykonawcze jest dobre dla benchmarkingu (np. wykrywanie, czy dołączony jest debugger lub czy optymalizacja jit jest wyłączona, co skutkowałoby nieprawidłowymi pomiarami).

2. Pomiar części kodu niezależnie (aby dokładnie zobaczyć, gdzie znajduje się wąskie gardło).

3. porównywanie różnych wersji/komponentów / fragmentów kodu (w pierwszym zdaniu mówisz "... benchmarking małych fragmentów kodu do zobacz, która implementacja jest najszybsza.').

Dotyczące #1:

• Aby wykryć, czy debugger jest dołączony, przeczytaj Właściwość System.Diagnostics.Debugger.IsAttached (pamiętaj, aby również obsłużyć przypadek, w którym debugger początkowo nie jest dołączony, ale jest dołączony po pewnym czasie).

• Aby wykryć, czy optymalizacja jit jest wyłączona, przeczytaj właściwość DebuggableAttribute.IsJITOptimizerDisabled odpowiednich zestawów:

  private bool IsJitOptimizerDisabled(Assembly assembly)
  {
      return assembly.GetCustomAttributes(typeof (DebuggableAttribute), false)
          .Select(customAttribute => (DebuggableAttribute) customAttribute)
          .Any(attribute => attribute.IsJITOptimizerDisabled);
  }
  

Dotyczące #2:

Dotyczące #3:

Jednym ze sposobów, aby to zrobić, jest zwrócenie wynik testu porównawczego jako silnie wpisany obiekt, który można łatwo wykorzystać w różnych kontekstach.

Innym podejściem jest wykorzystanie istniejącego komponentu do wykonania wskaźników. Właściwie, w mojej firmie zdecydowaliśmy się udostępnić nasze narzędzie do testów do domeny publicznej. W swoim rdzeniu zarządza garbage collector, jitter, warmups itp., tak jak sugerują niektóre z innych odpowiedzi tutaj. Ma również trzy cechy, które zaproponowałem powyżej. Zarządza kilkoma z tematy poruszane w Eric Lippert blog .

Jest to Przykładowe wyjście, w którym porównywane są dwa komponenty, a wyniki zapisywane są do konsoli. W tym przypadku porównywane dwa komponenty nazywane są 'KeyedCollection' i 'MultiplyIndexedKeyedCollection':

Istnieje pakiet NuGet , przykładowy pakiet NuGet, a kod źródłowy jest dostępny na GitHub. Istnieje również blog post .

Musisz również uruchomić" rozgrzewkę " przed rzeczywistym pomiarem, aby wykluczyć czas, jaki kompilator JIT spędza na jitowaniu kodu.

W zależności od kodu, na którym bazujesz i platformy, na której działa, może być konieczne uwzględnienie tego, jak wyrównanie kodu wpływa na wydajność . Aby to zrobić, prawdopodobnie wymaga zewnętrznego opakowania, które uruchamiało test wiele razy (w oddzielnych domenach aplikacji lub procesach?), czasami po raz pierwszy wywołując "padding code", aby wymusić jego kompilację JIT, tak aby Kod benchmarkingowy był różnie wyrównywany. Pełny wynik testu dałby najlepsze i najgorsze czasy dla różnych wyrównań kodu.

Jeśli próbujesz wyeliminować wpływ Garbage Collection z benchmark complete, czy warto ustawić GCSettings.LatencyMode?

Jeśli nie, a chcesz, aby wpływ śmieci utworzonych w func był częścią benchmarka, to czy nie powinieneś również wymusić zbierania na końcu testu (wewnątrz timera)?

Podstawowym problemem twojego pytania jest założenie, że pojedynczy pomiar może odpowiedzieć na wszystkie pytania. Musisz zmierzyć wielokrotnie, aby uzyskać efektywny obraz sytuacji i szczególnie w śmieciach zebranych jak C#.

Inna odpowiedź daje dobry sposób pomiaru podstawowej wydajności.

static void Profile(string description, int iterations, Action func) {
    // warm up 
    func();

    var watch = new Stopwatch(); 

    // clean up
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Start();
    for (int i = 0; i < iterations; i++) {
        func();
    }
    watch.Stop();
    Console.Write(description);
    Console.WriteLine(" Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds);
}

Jednak ten pojedynczy pomiar nie uwzględnia śmieci kolekcja. Odpowiedni profil dodatkowo stanowi najgorszy przypadek osiągi od śmieci rozrzuconych po wielu połączeniach (numer ten jest sortowany bezużyteczne, ponieważ VM może zakończyć się bez zbierania resztek śmieci, ale nadal jest przydatna do porównywania dwóch różnych implementacje func.)

static void ProfileGarbageMany(string description, int iterations, Action func) {
    // warm up 
    func();

    var watch = new Stopwatch(); 

    // clean up
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Start();
    for (int i = 0; i < iterations; i++) {
        func();
    }
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Stop();
    Console.Write(description);
    Console.WriteLine(" Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds);
}

I można też chcieć zmierzyć najgorszy przypadek wydajności garbage collection dla metody, która jest wywoływana tylko raz.

static void ProfileGarbage(string description, int iterations, Action func) {
    // warm up 
    func();

    var watch = new Stopwatch(); 

    // clean up
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Start();
    for (int i = 0; i < iterations; i++) {
        func();

        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect();
    }
    watch.Stop();
    Console.Write(description);
    Console.WriteLine(" Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds);
}

Ale ważniejsze niż zalecanie jakichkolwiek konkretnych możliwych dodatkowych pomiary do profilu to pomysł że należy mierzyć wiele różne statystyki, a nie tylko jeden rodzaj statystyki.