Извиквания на метод за сравнителен анализ в C#

Можете да използвате вградения клас Хронометър, за да „Осигурява набор от методи и свойства, които можете да използвате за точно измерване на изминалото време." ако търсите ръчен начин да го направите. Не съм сигурен обаче за автоматизирания.

Откраднато (и модифицирано) от отговора на Юрий:

private static void Benchmark(Action act, int iterations)
{
    GC.Collect();
    act.Invoke(); // run once outside of loop to avoid initialization costs
    Stopwatch sw = Stopwatch.StartNew();
    for (int i = 0; i < iterations; i++)
    {
        act.Invoke();
    }
    sw.Stop();
    Console.WriteLine((sw.ElapsedMilliseconds / iterations).ToString());
}

Често конкретен метод трябва да инициализира някои неща и не винаги искате да включите тези разходи за инициализация в общия си бенчмарк. Също така искате да разделите общото време за изпълнение на броя итерации, така че вашата оценка да е повече или по-малко независима от броя на итерациите.

Откраднах повечето от следното от метода на Jon Skeet за сравнителен анализ:

private static void Benchmark(Action act, int interval)
{
    GC.Collect();
    Stopwatch sw = Stopwatch.StartNew();
    for (int i = 0; i < interval; i++)
    {
        act.Invoke();
    }
    sw.Stop();
    Console.WriteLine(sw.ElapsedMilliseconds);
}

Ето някои неща, които открих чрез опити и грешки.

1. Изхвърлете първата партида от (хиляди) повторения. Те най-вероятно ще бъдат засегнати от JITter.
2. Изпълнението на бенчмарк на отделен Thread обект може да даде по-добри и по-стабилни резултати. Не знам защо.
3. Виждал съм някои хора да използват Thread.Sleep по някаква причина, преди да изпълнят бенчмарка. Това само ще влоши нещата. Не знам защо. Вероятно поради JITter.
4. Никога не стартирайте бенчмарка с разрешено отстраняване на грешки. Кодът най-вероятно ще работи с порядъци по-бавно.
5. Компилирайте приложението си с активирани всички оптимизации. Някои кодове могат да бъдат драстично повлияни от оптимизацията, докато други кодове няма да бъдат, така че компилирането без оптимизация ще повлияе на надеждността на вашия бенчмарк.
6. Когато компилирате с активирани оптимизации, понякога е необходимо по някакъв начин да оцените резултата от бенчмарка (напр. да отпечатате стойност и т.н.). В противен случай компилаторът може да „разбере“ някои изчисления за безполезни и просто няма да ги извърши.
7. Извикването на делегати може да има забележими допълнителни разходи при извършване на определени бенчмаркове. По-добре е да поставите повече от една итерация вътре в делегата, така че режийните разходи да имат малък ефект върху резултата от бенчмарка.
8. Профайлърите могат да имат свои собствени допълнителни разходи. Те са добри в това да ви кажат кои части от вашия код са тесни места, но не са добри в реалното сравняване на две различни неща надеждно.
9. Като цяло, фантастичните решения за сравнителен анализ могат да имат забележими разходи. Например, ако искате да сравните много обекти, използвайки един интерфейс, може да е изкушаващо да обвиете всеки обект в клас. Не забравяйте обаче, че конструкторът на класа също има допълнителни разходи, които трябва да бъдат взети под внимание. По-добре е всичко да е възможно най-просто и директно.

Звучи сякаш искате профилиращ профил. Аз лично бих препоръчал EQATEC Profiler, тъй като той е най-добрият безплатен, който съм пробвал. Хубавото на този метод в сравнение с обикновения хронометър е, че той също предоставя разбивка на производителността на определени методи/блокове.

Профайлърите дават най-добрите показатели, тъй като те диагностицират целия ви код, но го забавят много. Профайлърите се използват за намиране на тесни места.

За оптимизиране на алгоритъм, когато знаете къде са тесните места, използвайте речник на име-->хронометър, за да следите критичните за производителността секции по време на изпълнение.