Чи справді передчасна оптимізація є коренем усього зла?

Моя колега сьогодні здійснила клас під назвою ThreadLocalFormat, який, в основному, перемістив екземпляри класів Java Format в локальний потік, оскільки вони не є безпечними для потоків і "відносно дорогими" для створення. Я написав швидкий тест і підрахував, що я можу створити 200 000 екземплярів на секунду, запитав, чи він створює стільки, на що він відповів "ніде не так багато". Він чудовий програміст, і всі в команді є висококваліфікованими, тому ми не маємо проблем з розумінням отриманого коду, але це був очевидно випадок оптимізації, де немає реальної потреби. Він відмовив код на моє прохання. Що ти думаєш? Це випадок "передчасної оптимізації" і наскільки це насправді погано?

Важливо пам’ятати про повну цитату:

Слід забути про невелику ефективність, скажімо, про 97% часу: передчасна оптимізація - корінь усього зла. Але ми не повинні пропускати наші можливості на критичних 3%.

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

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

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

Назвіть кілька хороших ранніх оптимізацій у порядку важливості:

• Архітектурні оптимізації (структура програми, спосіб її складової та шаруватості)
• Оптимізація потоку даних (всередині та поза додатком)

Деякі оптимізації середнього циклу розвитку:

• Структури даних, введіть нові структури даних, які мають кращу продуктивність або при необхідності менші накладні витрати
• Алгоритми (зараз настав час приступити до вирішення між quicksort3 та hepsort ;-))

Деякі оптимізації циклу розвитку

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

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

Якщо продуктивність викликає занепокоєння (і завжди повинна бути), завжди думайте про велику . Продуктивність - це велика картина, а не про такі речі, як: я повинен використовувати int або long ?. Переходьте на Top Down, коли працюєте з продуктивністю замість Bottom Up .

оптимізація без першого вимірювання майже завжди передчасна.

Я вважаю, що це правда і в цьому випадку, і в загальному випадку.

Оптимізація "зла", якщо вона викликає:

• менш чіткий код
• значно більше коду
• менш захищений код
• витрачений час програміста

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

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

Ось більша цитата (зі сторінки 8 pdf, сторінка 268 в оригіналі):

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

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

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

Ще один непоганий шматочок з попередньої сторінки:

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

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

Взагалі, я думаю, що рання мікрооптимізація може бути поганою ідеєю. Однак макрооптимізація (такі, як вибір алгоритму O (log N) замість O (N ^ 2)) часто варта і повинна бути здійснена рано, оскільки може бути марно писати алгоритм O (N ^ 2) і потім повністю відкиньте його на користь підходу O (log N).

Зауважте, такі слова можуть бути : якщо алгоритм O (N ^ 2) простий і легкий для запису, його можна викинути пізніше без особливої ​​провини, якщо він виявиться занадто повільним. Але якщо обидва алгоритми однаково складні, або якщо очікувана завантаженість настільки велика, що ви вже знаєте, що вам знадобиться більш швидкий, то оптимізація на ранніх стадіях є надійним інженерним рішенням, яке в майбутньому скоротить ваше загальне навантаження.

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

• що струни коштують дорожче, ніж числа
• що динамічні мови набагато повільніші, ніж мови з статичним типом
• переваги списку масивів / векторів над пов'язаними списками, і навпаки
• коли користуватися хештелем, коли використовувати відсортовану карту та коли купувати
• що (якщо вони працюють з мобільними пристроями) "подвійний" та "інт" мають схожі показники роботи на робочих столах (FP може бути навіть швидшим), але "подвійний" може бути в сто разів повільніше на мобільних пристроях низького класу без FPU;
• що передача даних через Інтернет відбувається повільніше, ніж доступ до жорсткого диска, жорсткі диски значно повільніші за оперативну пам’ять, оперативна пам’ять набагато повільніше, ніж кеш-пам'ять L1 та регістри, а операції в Інтернеті можуть блокуватися на невизначений час (і виходити з ладу в будь-який час).

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

Маючи багато знань та особистий набір інструментів, ви можете оптимізувати майже без особливих зусиль. Докладати багато зусиль для оптимізації, яка може бути непотрібною - це зло (і я визнаю, що потрапляв у цю пастку не раз). Але коли оптимізація настільки проста, як вибір набору / хештелів замість масиву або збереження списку чисел у подвійному [] замість рядка [], то чому б ні? Я, можливо, не погоджуюся з Knuth тут, я не впевнений, але я думаю, що він говорив про оптимізацію низького рівня, тоді як я говорю про оптимізацію високого рівня.

Пам'ятайте, що ця цитата спочатку з 1974 року. У 1974 році комп'ютери були повільними, а обчислювальна потужність була дорогою, що дало деяким розробникам схильність до надмірного оптимізації. Я думаю, що саме на це натискав Кнут. Він не казав "не хвилюйся про продуктивність", тому що в 1974 році це були просто шалені розмови. Кнут пояснював, як оптимізувати; коротше кажучи, слід зосередитись лише на вузьких місцях, і перед цим потрібно виконати вимірювання, щоб знайти вузькі місця.

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

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

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

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

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

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

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

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

Подивіться на Боха. Це повільно, як пекло. Чи стане це коли-небудь швидше? Можливо, але лише в межах кількох відсотків. Він ніколи не отримає продуктивність, порівнянну з програмним забезпеченням для віртуалізації, таким як VMWare або VBox або навіть QEMU. Бо це повільно по дизайну!

Якщо проблема програмного забезпечення полягає в тому, що воно повільне, то тому, що воно ДУЖЕ повільне, і це можна виправити лише покращивши продуктивність на множину. + 10% просто не зробить повільне програмне забезпечення швидким. А пізніші оптимізації ви зазвичай не отримаєте більше 10%.

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

Я знаю, що насправді не відповідає вашому конкретному випадку, але це відповідає на загальне питання "Чи справді передчасна оптимізація є коренем усього зла?" - з чітким НІ.

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

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

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

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

Так, в основному, так, це звучить як передчасна оптимізація, але я не обов'язково відмовлятись від неї, якщо вона не вводить помилки - адже вона зараз оптимізована (!)

Я вважаю, що Майк Кон називає код «позолотою» - тобто витрачати час на речі, які можуть бути приємними, але не потрібні.

Він радив проти цього.

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

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

Але в цілому оптимізація призводить до менш читабельного та менш зрозумілого коду, і його слід застосовувати лише за необхідності. Простий приклад - якщо ви знаєте, що вам доведеться сортувати лише пару елементів - тоді використовуйте BubbleSort. Але якщо ви підозрюєте, що елементи можуть збільшитися, і ви не знаєте на скільки, то оптимізація за допомогою QuickSort (наприклад) не є злом, а обов'язковою. І це слід враховувати під час проектування програми.

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

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

Це призводить до появи коду, який важче зрозуміти (погано), і витрачає багато часу на роботу, яка, ймовірно, не корисна (погана).

З іншого боку, я вважаю, що більшість програмістів / розробників не планують успіх, і "прототип" майже завжди стає випуском 1.0. Я маю досвід з 4-х окремих оригінальних продуктів, в яких стильний, сексуальний та високофункціональний фронт-інтерфейс (в основному інтерфейс користувача) призвів до широкого поширення та захоплення користувачів. У кожному з цих продуктів проблеми з роботою почали повстати протягом відносно коротких термінів (від 1 до 2 років), особливо коли більші, більш вимогливі клієнти почали сприймати продукт. Дуже скоро ефективність домінувала у списку питань, хоча нова функція розвитку домінувала у списку пріоритетів управління. Клієнти ставали все більш розчаровані, оскільки кожен випуск додавав нові функції, які звучали чудово, але були майже недоступні через проблеми з продуктивністю.

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

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

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

Коли повторюється приказка як привід для того, щоб не написати ефективний код (C ++, VB, T-SQL чи іншим чином), або не правильно розробити сховище даних або не врахувати архітектуру мережі, то IMO вони просто демонструють дуже неглибоке розуміння реального характеру нашої роботи. Промінь

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

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

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

Одним із прикладів цього я можу описати - модель даних, яку я колись робив для системи управління судовими справами, в якій було близько 560 таблиць. Він розпочався нормалізованим («прекрасно нормалізований», як сказав консультант певної фірми «великої 5»), і нам довелося лише помістити в нього чотири статті денормалізованих даних:

• Один матеріалізований вигляд для підтримки екрана пошуку

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

• Один денормалізований звітний стіл (це існувало лише тому, що нам довелося брати деякі звіти про пропускну здатність, коли проект сховища даних був консервований)

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

Це був (на той час) найбільший проект J2EE в Австралазії - це вже понад 100 років часу розробника - і в ньому було 4 денормалізованих елемента в схемі бази даних, один з яких насправді там взагалі не належав.

Передчасна оптимізація не є коренем ВСЕГО зла, це точно. Однак є і недоліки:

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

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

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

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

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

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

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

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

Ознайомтеся з цим чудовим твором про те, що ПМО може означати чи не може означати.