У який момент слід почати думати про продуктивність?

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

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

Оновлення

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

Відстрочка міркувань щодо ефективності іноді базується на неправильному застосуванні фрази:

Передчасна оптимізація - корінь усього зла.

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

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

Існує ряд речей, які ви можете зробити під час розвитку, щоб досягти хороших показників, без езотеричних (і передчасних) оптимізацій:

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

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

Ось про що НЕ ДУМАЙТЕ:

• Чи ++iшвидше, ніж i++?
• Чи switchшвидше, ніж if?
• Чи повинен я виконувати inlineсвої функції?
• Віртуальні функції повільні?
• Це C ++ / Java / C # швидше / повільніше, ніж інші?
• бла, бла, ...

Ось що думати про:

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

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

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

Ніхто не повинен думати про ефективність роботи (особливо при розробці баз даних) з самого початку. Багато нашкодили нашій галузі люди, які вважають, що будь-яка оптимізація - це передчасна оптимізація. Цитата була споконвічно покликана не дати людям дивитися на мікрооптимізацію до появи проблеми. Це не передбачалося взагалі не робити оптимізації. Наприклад, у базі даних є багато відомих технологій, які погано працюють. Уникання тих, що в дизайні, є частиною того, що вам потрібно зробити. Дуже важко переробити базу даних із 100 000 000 записів, оскільки вона була розроблена з використанням погано перформіруючих методів, і ми більше не можемо уникнути проблеми, купуючи краще обладнання.

Спершу турбуйтеся про правильність ¹ , потім ремонтопридатність, безпеку та надійність, а потім можна подумати про продуктивність. Застосовуйте це замовлення до кожного фрагмента коду під час його розробки. Цілком можливо, що ефективне рішення може випасти, просто виклавши речі чіткі та прості.

80% продуктивності - це вибір правильного алгоритму та структури даних для проблеми; погано оптимізований квакісорт все ще вибиває штани з високооптимізованого сорту міхура в середньому випадку (найгірший випадок - нічия).

Те, що всі на SO намагаються применшити, - це "швидше, ++ p або p ++", мислення, де люди настільки потрапляють у перехитровування компілятора, що вони втрачають сліди про більшу проблему, в результаті чого код крихкий, помилка -впевне, неправильне , а найкраще, не те, що набагато швидше, ніж більш просте рішення. Я мав справу з таким кодом з перших рук; один приклад був настільки крихким, що ми не могли внести жодних змін, не порушивши їх повністю.

¹ Де "правильність" означає "виконання специфікації", що не є синонімом "без помилок".

Вам слід почати думати про продуктивність, як тільки зрозумієте, що таке "хороша" ефективність. Іншими словами, було б неправильно починати думати про ефективність, перш ніж визначити, що таке пороги:

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

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

Щоб придумати ці показники, ви повинні зрозуміти, що потрібно робити вашій системі. Наприклад, чи потрібні показники абсолютної продуктивності (відповідь протягом X часу) чи вимагаються вимірювання пропускної здатності (X відповідей за Y час)? Оптимізація пропускної здатності та абсолютного часу вимагає різних підходів, і якщо ви не знаєте, що насправді важливо, ви можете оптимізувати неправильний шлях.

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

Незважаючи на це, немає нічого поганого в тому, щоб думати про продуктивність на початковому етапі кодування, якщо ви знаєте певні прийоми, які дійсно зміняться. Наприклад, вибір однієї структури зберігання з бібліотеки над іншою, оскільки минулий досвід навчив вас, що одна з них швидша / використовує менше оперативної пам’яті, ніж інша. Або створення простої (ви можете зробити її більш складною, якщо це вимагає наступне тестування), система кешування даних, які ви знаєтеДоступ буде багато, і він буде набагато краще кешований. Таким чином, ви не надто дбаєте про ефективність роботи (принаймні, не спочатку), але використовуєте поради та хитрощі, які ви навчились з інших проектів. Постарайтеся зберегти ці прості, щоб їх було легко включити під час початкової розробки, а також можуть бути певні переваги.

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

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

Збалансований підхід був би кращим. Продуктивність важлива, але не настільки важлива, як виконання справ, тому:

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

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

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

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

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

Це набагато кращий підхід і з точки зору ремонту.

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

По-справжньому гарна текстова стаття про продуктивність: Гра в оболонці продуктивності комп'ютера .

Гра в оболонку продуктивності комп'ютера, також відома як «знайти вузьке місце», завжди грається між цими чотирма ресурсами:

• ЦП
• Диск
• Мережа
• Пам'ять

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

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

• У вас багато пам’яті? - ви отримаєте кращі показники роботи зі структурою даних "все в пам'яті", але якщо у вас недостатньо заміни пам'яті, це знищить вашу ефективність.
• Вам потрібна наполегливість? База даних надає цілісність, але повільніше, ніж вищевказана структура даних "все в пам'яті". МНОГО повільніше.
• Чи можете ви кешувати результати? Лак може допомогти у цьому! http://www.varnish-cache.org/

Список продовжується і продовжується.

Що ви можете зробити, це написати «найпростіше , що могло б працювати» від знання , які ви в даний час у є, і зробити це в модульному моди , так що ви можете легко реорганізовувати , коли ви знаєте більше. Зауважте, що "найпростіша" річ не обов'язково проста!

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

Принаймні теоретично, ви повинні почати думати про ефективність, як тільки ви проходите бета-тестування, а не раніше.

Однак це не є ліцензією на прийняття поганих дизайнерських рішень. Наприклад, використання рядка NVARCHAR в якості основного ключа - це вірний шлях до низької продуктивності; але сказати, це брудна звичка, незалежно від продуктивності, і не варто її використовувати в першу чергу.

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

HTH

Це залежить. Корисно мати на увазі правило 80/20: більшість (скажімо, 80%) коду в додатку ніколи не буде виконуватися досить часто, щоб помітно змінити продуктивність. Вам потрібно зосередитись на решті 20%, де додаток повинен витратити близько 80% часу його виконання.

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

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

Це залежить від того, на якій стадії розвитку ви перебуваєте

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

2) Після того, як будівельні блоки будуть інтегровані, ви отримаєте натяк на химерність ресурсів, там у вас є місце для оптимізації.

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

Важливо, які дії ви будете робити на основі всього цього мислення. Думки дешеві, але дії можуть порушити код і підірвати терміни.

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

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

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

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

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

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

IMHO важливо подумати про ефективність, перш ніж впроваджувати систему, а лише думати про це. Ви повинні проаналізувати програму та з’ясувати, які можуть бути потенційні вузькі місця.

Потім реалізуйте систему максимально просто. Якщо виникають проблеми з продуктивністю, то оптимізуйте.

Наприклад, скажіть, що у вас є клієнт GUI, який отримує дані через якусь послугу (SOAP, REST HTTP тощо). Тоді найголовніше для високої продуктивності / масштабованості - це мати якомога менше дзвінків, кожен виклик повертає багато даних, а не те, що багато дзвінків повертають трохи інформації в кожному, тобто віддають перевагу здоровенному спілкуванню перед чаткою.

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

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

Можливо, ви також захочете отримати ефективні звички, але це залежатиме від мови. Наприклад, у C ++, "++ i;" як окреме твердження або вираз завжди принаймні так само добре, як "i ++;", і потенційно може бути набагато ефективнішим. Однак у більшості випадків слід написати чіткий код і довіряти компілятору. Увійти в звичку турбуватися про мікроефективність майже напевно викличе у вас більше проблем, ніж це вирішує. Для настільних додатків, або компілятор, по крайней мере так розумні , як ви про таких речах , як i >> 1VS. i / 2або кращий спосіб поліпшити продуктивність, щоб отримати кращий компілятор, так що не турбуйтеся про це.

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

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

Коли я повинен почати думати про це? Скільки зусиль я повинен докласти до цього? Це залежить від масштабу півня проекту. (Іншими словами, який ризик не мати хороших показників?)

Вивчіть основи заздалегідь (див Роберт Харві відповідь ). Для того, щоб застосувати мислення, орієнтоване на ефективність, на різних етапах розробки програмного забезпечення, розробник повинен знати це зсередини, щоб мисленнєвий процес не заважав цим додатковим міркуванням. (Іншими словами, почніть думати про ефективність ще до задуму проекту.)

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

Потім, залежно від характеру вашого проекту та його шкали півні:

• Швидке прототипування, або "вибуття коду, як завтра немає", або внутрішня розробка з низьким впливом на бізнес: просто ведіть статистику. Ще не думайте про продуктивність. Реалізуйте функцію найпростішим способом. Дотримуйтесь першого алгоритму, який вам спадає на думку.

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

• Настільні програми, які потребують послідовного, всебічного підходу до продуктивності. Це не повинно бути сильно оптимізованим; однак, повинно бути якомога менше "зависань" (невідповідності).

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

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

  • Призначте когось із вашої команди, який буде відповідальним за аналіз та звітність статистики ефективності.
  • Складайте теорії про характеристики продуктивності, перевіряйте експерименти та порівнюйте свої прогнози зі спрощеними моделями Comp Sci.
  *

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

Тримайте тести на працездатність протягом усього життя проекту як тест регресії. Код технічного обслуговування не відомий для запуску проблем із роботою, оскільки часто виправляють дуже вузьку увагу.

Я завжди покладаюся на просту формулу:

1. Зроби так, щоб він працював
2. Зроби це правильно
3. Зробіть це швидко

... в тому порядку.

Згідно c2 , ця рецептура приписується Кенту Беку .