poniedziałek, 22 sierpnia 2011

C# - pomiar czasu wykonania kodu

Udało mi się dzisiaj zakończyć implementację projektu w C# (C Sharp), który już raz był inspiracją do postu na tym blogu. Przyszła więc pora na przeprowadzenie testów na aplikacji. Poza sprawdzeniem wymagań funkcjonalnych konieczne jest zbadanie wszystkich wymagań niefunkcjonalnych. Najłatwiejsze z nich do sprawdzenia, to czas realizacji funkcjonalności. Dzisiaj więc post o pomiarze czasu wykonania kodu w C#. Stosuję elegancką i wygodną metodę z C# 2.0.

Metoda w C# 2.0, której używam jest najbardziej elegancką metodą pomiaru czasu jaką dotąd stosowałem w aplikacjach. Mierzyłem czas wykonania kodu w Javie, ASM, Android API czy PHP, ale C# ma tu faktycznie duży plus.

Aby zmierzyć czas korzystamy z klasy Stopwatch, która znajduje się w przestrzeni nazw System.Diagnostics. Jak sama nazwa wskazuje jest to stoper. Poniżej krótki przykład jak z niej skorzystać.
Stopwatch sw = new Stopwatch();
sw.Start();
//kod poddany pomiarowi
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);

Jak łatwo zauważyć tak jak zwykły stoper należy go wystartować, a następnie po wykonanym pomiarze zatrzymać. W zasadzie, to można jego wskazanie pobrać i bez zatrzymywania jeśli potrzeba podać czas na bieżąco. Bardzo miłą opcją jest to, że czas ze stopera można pobrać w tyknięciach zegara (jak w ASM). Pozwala to na bardzo dużą dokładność. Jeśli nie pomyliłem się w obliczeniach, to w przypadku mojej maszyny pozwala to na dokładność do 0.0353[ns]!

Czytaj też:

4 komentarze:

  1. Na mój gust to się walnąłeś i to tak co najmniej o rząd wielkości.

    OdpowiedzUsuń
  2. @Anonimowy bardzo możliwe, ale 352ms to 1036430 tyknięć. O ile mi się zdaje matematyka prosta wystarczy i posłużenie się dzieleniem i potęgami wystarczy do określenia ile czasu trwa jeden tik.

    OdpowiedzUsuń
  3. Ale ty napisałeś o setnych częściach NANOsekundy, a to jest po prostu niefizyczne. Mając CPU z zegarem 1GHz jeden takt wychodzi długości 1ns. Przy szybkim - "współczesnym" procku 3GHz będzie to więc ~0.3ns, ale na pewno nie o rząd wielkości krócej tak jak napisałeś :-)

    Zupełnie odrębną kwestią natomiast jest po cholerę komuś przy mierzeniu czasu rozdzielczość na poziomie taktów procesora. W normalnym programie, który rysuje GUI, odpytuje bazę danych, ciągnie coś z sieci itd... te operacje zajmują dziesiątki czy setki ms, a sam program zwykle działa w środowisku wielozadaniowym. W związku z czym mierzenie tego z dokładnością do taktów CPU jest zwyczajnie bezsensowne.

    OdpowiedzUsuń
  4. @Anonimowy taki pomiar może i jest bez sensu, ale jeśli przypadkiem z jakiegoś powodu się przyda, to jest taka możliwość. W programowaniu wysokopoziomowym nie ścigałem się jeszcze z nikim na takty, ale pisząc w ASM na DLX i owszem. Każdy jeden takt krócej był na wagę złota.

    OdpowiedzUsuń