Поради щодо оптимізації програм C # /. NET [закрито]

Здається, оптимізація - це втрачене мистецтво в наші дні. Хіба не було часу, коли всі програмісти вичавлювали кожну унцію ефективності зі свого коду? Часто роблячи це, проходячи п’ять миль по снігу?

У дусі повернення втраченого мистецтва, які кілька порад ви знаєте для простих (або, можливо, складних) змін для оптимізації коду C # /. NET? Оскільки це настільки широка річ, яка залежить від того, що хтось намагається досягти, це допомогло б надати контекст вашій підказці. Наприклад:

• При об'єднанні багатьох рядків разом StringBuilder замість цього. Див. Посилання внизу щодо застережень щодо цього.
• Використовуйте string.Compare для порівняння двох рядків, замість того, щоб робити щось подібнеstring1.ToLower() == string2.ToLower()

Загальний консенсус на даний момент, як видається, є ключовим. Цей тип пропускає сенс: вимірювання не говорить вам, що не так, або що з цим робити, якщо ви зіткнетеся з вузьким місцем. Одного разу я зіткнувся з вузьким місцем об’єднання рядків і не знав, що з цим робити, тому ці поради корисні.

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

Хоча я бачу, що може бути корисним також знати, чому підказка корисна і де її слід застосовувати. Для StringBuilderпідказки я знайшов допомогу, яку давно зробив тут, на сайті Джона Скіта .

Здається, оптимізація - це втрачене мистецтво в наші дні.

Був раз на день, коли виготовлення, скажімо, мікроскопів практикувалось як мистецтво. Оптичні принципи були погано вивчені. Не було стандартизації деталей. Трубки, шестірні та лінзи повинні були виготовляти вручну висококваліфіковані робітники.

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

Те, що аналіз продуктивності є "втраченим мистецтвом", це дуже, дуже добре. Це мистецтво практикувалось як мистецтво . Слід підходити до оптимізації для того, що це таке: інженерна проблема вирішується шляхом ретельного застосування твердих інженерних принципів.

Протягом багатьох років мене десятки разів запитували у мене перелік "порад та підказок", які люди можуть використовувати для оптимізації своїх vbscript / jscript / своїх активних сторінок сервера / своїх VB / своїх кодів C #. Я завжди противлюсь цьому. Підкреслювати "поради та підказки" - це зовсім неправильний спосіб підійти до ефективності. Цей шлях призводить до коду, який важко зрозуміти, важко міркувати, важко підтримувати, який, як правило, не помітно швидший, ніж відповідний прямий код.

Правильний спосіб підійти до продуктивності - підійти до неї як до інженерної проблеми, як до будь-якої іншої проблеми:

• Ставте значущі, вимірювані, орієнтовані на споживача цілі.
• Створіть тестові набори, щоб перевірити свою ефективність щодо цих цілей в реалістичних, але контрольованих та повторюваних умовах.
• Якщо ці апартаменти показують, що ви не досягаєте своїх цілей, використовуйте такі інструменти, як профілі, щоб з’ясувати, чому.
• Оптимізуйте зловмисники того, що профілювач визначає як найгіршу підсистему. Продовжуйте профілювати кожну зміну, щоб ви чітко розуміли вплив продуктивності кожної з них.
• Повторюйте, поки не відбудеться одна з трьох речей (1) ви досягнете своїх цілей і поставите програмне забезпечення, (2) ви переглянете цілі вниз до чогось, що ви можете досягти, або (3) ваш проект буде скасовано, оскільки ви не змогли досягти своїх цілей.

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

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

Отримайте хороший профайлер.

Не турбуйтеся, навіть намагаючись оптимізувати C # (насправді, будь-який код) без хорошого профайлера. Насправді це надзвичайно допомагає мати під рукою як дискретизацію, так і трасування.

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

Першими трьома кроками до профілювання завжди повинні бути 1) Міра, 2) Міра, а потім 3) Міра ....

Рекомендації щодо оптимізації:

1. Не робіть цього, якщо вам не потрібно
2. Не робіть цього, якщо дешевше кинути на проблему нове обладнання замість розробника
3. Не робіть цього, якщо ви не зможете виміряти зміни у виробничому еквівалентному середовищі
4. Не робіть цього, якщо ви не знаєте, як користуватися центральним процесором та профайлером пам'яті
5. Не робіть цього, якщо це зробить ваш код нечитабельним або неможливим

Оскільки процесори продовжують швидше розвиватися, основним вузьким місцем у більшості додатків є не процесор, це пропускна здатність: пропускна здатність до позачипової пам'яті, пропускна здатність до диска та пропускна здатність до мережі.

Почніть з дальнього кінця: використовуйте YSlow, щоб зрозуміти, чому ваш веб-сайт повільний для кінцевих користувачів, а потім поверніться назад і зафіксуйте доступ до бази даних, щоб він був не надто широким (стовпці) і не надто глибоким (рядки).

У дуже рідкісних випадках, коли варто зробити що-небудь для оптимізації використання центрального процесора, будьте обережні, щоб не впливати негативно на використання пам’яті: я бачив „оптимізацію”, коли розробники намагалися використовувати пам’ять для кешування результатів для збереження циклів процесора. Мережевий ефект полягав у зменшенні доступної пам’яті на кеш-сторінки та результати баз даних, що робило роботу програми набагато повільнішою! (Див. Правило щодо вимірювання.)

Я також бачив випадки, коли "тупий" неоптимізований алгоритм перемагав "розумний" оптимізований алгоритм. Ніколи не недооцінюйте того, наскільки добрими стали компілятори та розробники чіпів, перетворюючи `` неефективний '' цикл циклу в супер ефективний код, який може повністю працювати в вбудованій пам'яті з конвеєрною обробкою. Ваш "розумний" алгоритм на основі дерева з розгорнутим внутрішнім циклом, що відлічує назад, що ви вважали "ефективним", можна перемогти просто тому, що він не міг залишатися в пам'яті мікросхеми під час виконання. (Див. Правило щодо вимірювання.)

При роботі з ORM пам’ятайте про N + 1 Selects.

List<Order> _orders = _repository.GetOrders(DateTime.Now);
foreach(var order in _orders)
{
    Print(order.Customer.Name);
}

Якщо клієнти не будуть охоче завантажені, це може призвести до кількох зворотних поїздок до бази даних.

• Не використовуйте магічні числа, використовуйте перелічення
• Не варто твердо кодувати значення
• Використовуйте дженерики, де це можливо, оскільки це безпечно для типу та уникає боксу та розпакування
• Використовуйте обробник помилок там, де це вкрай необхідно
• Утилізувати, розпоряджатися, розпоряджатися. CLR не знає, як закрити підключення до бази даних, тому закрийте їх після використання та утилізуйте некеровані ресурси
• Використовуйте здоровий глузд!

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

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

Зробіть це 10-20 разів, і ви зрозумієте, яка оптимізація може насправді змінити ситуацію.

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

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

• Спробуйте вирішити проблему, використовуючи лише (або: переважно) низькорівневі типи чи масиви з них.
• Проблеми часто невеликі - використання розумного, але складного алгоритму не завжди змушує вас перемагати, особливо якщо менш розумний алгоритм може бути виражений у коді, який використовує (масиви) типи низького рівня. Візьмемо для прикладу InsertionSort vs MergeSort для n <= 100 або алгоритм пошуку Dominator Tarjan проти використання бітвекторів для наївного вирішення форми потоку даних задачі для n <= 100. (100, звичайно, просто для того, щоб дати вам якусь ідею - профіль !)
• Подумайте про написання особливого випадку, який можна вирішити за допомогою лише низькорівневих типів (часто екземпляри проблем розміром <64), навіть якщо вам доведеться тримати інший код для більших екземплярів проблем.
• Вивчіть порозрядну арифметику, щоб допомогти вам у двох наведених вище ідеях.
• BitArray може бути вашим другом, порівняно зі словником, або ще гірше, List. Але пам’ятайте, що реалізація не є оптимальною; Ви можете написати швидшу версію самостійно. Замість того, щоб перевіряти, що ваші аргументи виходять за межі діапазону тощо, ви часто можете структурувати свій алгоритм так, щоб індекс все одно не міг вийти за межі діапазону - але ви не можете видалити перевірку зі стандартного BitArray, і це не безкоштовно .
• Як приклад того, що ви можете зробити лише з масивами низькорівневих типів, BitMatrix - це досить потужна структура, яка може бути реалізована як просто масив ulong, і ви навіть можете пройти її, використовуючи ulong як "фронт", тому що ви можете взяти найнижчий біт за постійний час (порівняно з чергою у першому пошуку ширини - але очевидно порядок інший і залежить від індексу елементів, а не від чистого порядку, в якому ви їх знаходите).
• Ділення та модуль дійсно повільні, якщо правий бік не є константою.
• Математика з плаваючою точкою - це не так в цілому повільніша за цілочисельну математику (не "те, що ти можеш зробити", а "те, що ти можеш пропустити")
• Розгалуження не є безкоштовним . Якщо ви можете уникнути цього, використовуючи просту арифметику (що завгодно, окрім ділення або за модулем), іноді ви можете отримати певні результати. Переміщення гілки за межі петлі майже завжди є гарною ідеєю.

Люди мають смішні уявлення про те, що насправді має значення. Переповнення стеку рясніє питаннями, наприклад, про ++iбільш "продуктивність", ніж i++. Ось приклад реального налаштування продуктивності , і це в основному однакова процедура для будь-якої мови. Якщо код просто написаний певним чином "тому що це швидше", це здогадки.

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

Правда полягає в тому, що не існує такого поняття, як ідеально оптимізований код. Однак ви можете оптимізувати для певної частини коду у відомій системі (або наборі систем) на відомому типі центрального процесора (і підрахунку), відомій платформі (Microsoft? Mono ?), Відомому фреймворку / версії BCL , відома версія CLI, відома версія компілятора (помилки, зміни специфікацій, налаштування), відома кількість загальної та доступної пам'яті, відоме походження збірки ( GAC «диск? віддалений»), з відомими фоновими діями системи з інших процесів.

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

Скажіть компілятору, що робити, а не як це робити. Як приклад, foreach (var item in list)краще ніж for (int i = 0; i < list.Count; i++)і m = list.Max(i => i.value);краще ніж list.Sort(i => i.value); m = list[list.Count - 1];.

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

Зрештою (і це стосується всього програмування) мінімізуйте цикли та мінімізуйте те, що ви робите в циклах. Ще більш важливим є мінімізація кількості петель всередині ваших петель. Яка різниця між алгоритмом O (n) та O (n ^ 2)? Алгоритм O (n ^ 2) має цикл всередині циклу.

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