Чи можна порівняти зразки невеликих кодів у C #, покращити цю реалізацію?

Досить часто на SO так я опиняюсь у порівнянні невеликих фрагментів коду, щоб побачити, яка реалізація найшвидша.

Досить часто я бачу коментарі, що тест-код не враховує джитінг або сміттєзбірник.

У мене є така проста функція бенчмаркінгу, яку я повільно розвивав:

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

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

Використання:

Profile("a descriptions", how_many_iterations_to_run, () =>
{
   // ... code being profiled
});

Чи має ця реалізація недоліки? Чи достатньо добре, щоб показати, що реалізація X швидша, ніж впровадження Y за Z ітерації? Чи можете ви придумати будь-які способи, які б ви покращили?

EDIT Цілком очевидно, що кращим є підхід на основі часу (на відміну від ітерацій), чи має хто-небудь реалізація, де перевірка часу не впливає на ефективність?

Ось модифікована функція: за рекомендацією спільноти, не соромтесь вносити зміни до цього свого вікі спільноти.

static double Profile(string description, int iterations, Action func) {
    //Run at highest priority to minimize fluctuations caused by other processes/threads
    Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High;
    Thread.CurrentThread.Priority = ThreadPriority.Highest;

    // 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);
    return watch.Elapsed.TotalMilliseconds;
}

Переконайтеся, що ви компілюєте в Release з увімкненими оптимізаціями та запускаєте тести поза Visual Studio . Ця остання частина важлива, оскільки JIT вказує свої оптимізації за допомогою відладчика, навіть у режимі випуску.

Фіналізація не обов'язково буде завершена до GC.Collectповернення. Фіналізація ставиться в чергу, а потім виконується на окремій потоці. Цей потік все ще може бути активним під час ваших тестів, впливаючи на результати.

Якщо ви хочете переконатися, що фіналізація завершена перед початком тестів, вам, можливо, захочеться зателефонувати GC.WaitForPendingFinalizers, який буде заблокований, поки не буде очищена черга на завершення:

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

Якщо ви хочете вийняти взаємодію GC з рівняння, ви можете запустити «розігрівати» дзвінок після виклику GC.Collect, не раніше. Таким чином, ви знаєте .NET вже буде мати достатню кількість пам'яті, виділеної з ОС для робочого набору вашої функції.

Майте на увазі, що ви робите нелінійний виклик методу для кожної ітерації, тому переконайтесь, що ви порівнюєте тестувані речі з порожнім корпусом. Вам також доведеться погодитись, що ви можете надійно зафіксувати час, який у кілька разів довший, ніж виклик методу.

Крім того, залежно від того, який тип матеріалу ви профілюєте, ви, можливо, захочете виконувати час роботи на основі певного часу, а не на певну кількість ітерацій - це може призвести до більш порівнянних цифр без наявність дуже короткого періоду для найкращого впровадження та / або дуже довгого для гіршого.

Я б взагалі не передавав делегата:

1. Виклик делегата - це віртуальний метод виклику. Не дешево: ~ 25% найменшого розміщення пам'яті у .NET. Якщо вас цікавлять деталі, дивіться, наприклад, це посилання .
2. Анонімні делегати можуть призвести до використання закриття, про що ви навіть не помітите. Знову ж таки, доступ до полів закриття помітніший, ніж наприклад, доступ до змінної на стеку.

Приклад коду, що призводить до використання закриття:

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

Якщо ви не знаєте про закриття, перегляньте цей метод у .NET Reflector.

Я думаю, що найважчу проблему подолати за допомогою таких методів бенчмаркінгу, як це, - це облік кращих випадків і несподіваних. Наприклад - "Як обидва фрагменти коду працюють при високому завантаженні процесора / використанні мережі / обміні диска / тощо". Вони чудово підходять для базових логічних перевірок, щоб побачити, чи працює певний алгоритм значно швидше, ніж інший. Але для правильної перевірки більшості функцій коду вам доведеться створити тест, який вимірює конкретні вузькі місця цього конкретного коду.

Я б ще сказав, що тестування невеликих блоків коду часто має незначну віддачу від інвестицій, і це може заохотити використання надмірно складного коду замість простого коду, який можна отримати. Написання чіткого коду, який інші розробники, або я ще 6 місяців за лінією, швидко зрозуміють, матиме більше переваг від продуктивності, ніж високооптимізований код.

Я б подзвонив func()кілька разів на розминку, а не лише одну.

Пропозиції щодо вдосконалення

1. Виявлення, чи добре середовище виконання для бенчмаркінгу (наприклад, виявлення того, чи не встановлено налагоджувальну систему чи оптимізація jit відключена, що може призвести до неправильних вимірювань).

2. Вимірювання частин коду самостійно (щоб точно побачити, де знаходиться вузьке місце).

3. Порівнюючи різні версії / компоненти / шматки коду (У першому реченні ви говорите "... порівняльний аналіз невеликих шматочків коду, щоб побачити, яка реалізація найшвидша.").

Щодо №1:

• Щоб визначити, чи налагоджено налагоджувач, прочитайте властивість System.Diagnostics.Debugger.IsAttached(Не забудьте також обробляти той випадок, коли налагоджувач спочатку не приєднаний, а додається через деякий час).

• Щоб виявити, чи оптимізація jit відключена, прочитайте властивість DebuggableAttribute.IsJITOptimizerDisabledвідповідних зборів:

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

Щодо № 2:

Це можна зробити багатьма способами. Один із способів - дозволити надання декількох делегатів, а потім виміряти цих делегатів окремо.

Щодо №3:

Це також можна зробити багатьма способами, і різні випадки використання вимагають дуже різних рішень. Якщо орієнтир викликається вручну, то запис у консоль може бути чудовим. Однак якщо еталонна система автоматично виконується системою збірки, то, можливо, запис на консоль, мабуть, не настільки тонкий.

Один із способів зробити це - повернути результат еталону як сильно набраний об'єкт, який легко може бути використаний у різних контекстах.

Etimo.Benchmarks

Інший підхід - використовувати існуючий компонент для виконання орієнтирів. Власне, у моїй компанії ми вирішили випустити наш інструмент орієнтиру у загальнодоступне надбання. За своєю суттю, він управляє збирачем сміття, тремтінням, розминками тощо, як і деякі інші відповіді. Він також має три функції, які я запропонував вище. Він керує кількома питаннями, обговореними в блозі Еріка Ліпперта .

Це приклад виведення, де порівнюються два компоненти і результати записуються на консоль. У цьому випадку два порівняні компоненти називаються "KeyedCollection" і "MultiplyIndexedKeyedCollection":

Є пакет NuGet , зразок пакету NuGet, а вихідний код доступний у GitHub . Також є публікація в блозі .

Якщо ви поспішаєте, я пропоную вам отримати зразок упаковки та просто змінити делегати зразка за потребою. Якщо ви не поспішаєте, може бути корисною ознайомитися з дописом у блозі, щоб зрозуміти деталі.

Ви також повинні виконати пропуск "прогрівання" перед фактичним вимірюванням, щоб виключити час, який компілятор JIT витрачає на обшивання коду.

Залежно від коду, який ви оцінюєте, і платформи, на якій він працює, вам може знадобитися врахувати, як вирівнювання коду впливає на продуктивність . Для цього, ймовірно, знадобиться зовнішня обгортка, яка виконувала тест кілька разів (в окремих доменних програмах чи процесах?); Деякі з них вперше викликали "код підкладки", щоб змусити його складати JIT, щоб змусити код бути орієнтир, щоб вирівняти по-різному. Повний результат тесту дасть найкращі та найгірші строки для різних вирівнювань коду.

Якщо ви намагаєтесь усунути вплив збору сміття з еталону, чи варто його встановити GCSettings.LatencyMode?

Якщо ні, і ви хочете, щоб вплив створеного сміття funcбув частиною еталону, то чи не слід також змушувати збирання в кінці тесту (всередині таймера)?

Основна проблема вашого запитання - припущення, що одне вимірювання може відповісти на всі ваші запитання. Вам потрібно виміряти кілька разів, щоб отримати ефективне уявлення про ситуацію, особливо в зібраному сміттям мовою типу C #.

Ще одна відповідь дає нормальний спосіб вимірювання базових показників.

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);
}

Однак це єдине вимірювання не враховує збирання сміття. Належний профіль додатково пояснює найгірший показник ефективності вивезення сміття, який розповсюджується на багато дзвінків (цей номер є марним, оскільки VM може припинитись, не збираючи жодного разу залишеного сміття, але все ще корисний для порівняння двох різних реалізацій 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);
}

Можна також виміряти найгірший показник ефективності вивезення сміття за методом, який викликається лише один раз.

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);
}

Але важливіше, ніж рекомендувати будь-які конкретні можливі додаткові вимірювання для профілювання, - це ідея, що слід вимірювати кілька різних статистичних даних, а не лише один вид статистики.