На вступних заняттях до курсу з оптимізації обговорюємо зі студентами таке питання, як «Коли починати оптимізувати»? Часто можна почути відповідь, яку приписують Дональду Кнуту: «Передчасна оптимізація — корінь усіх бід».
Зазвичай цю фразу (насправді вирвану з контексту) трактують так: не можна починати оптимізувати програму, доки її не написано й не протестовано. Мотивація тут така: а) до завершення розробки неможливо оцінити продуктивність усієї системи загалом; б) оптимізації можуть призвести до нечитабельного коду, який також дуже важко налагоджувати. Ці твердження сприймають як догму, попри те, що автора до цієї фрази привели певні міркування, без яких сама цитата позбавлена сенсу.
Звернімося до першоджерел. Згадану цитату можна знайти у статті: Knuth, D. E. 1974. Structured Programming with go to Statements. ACM Comput. Surv. 6, 4 (Dec. 1974), 261-301.
В оригінальній публікації Кнут розповідав про те, що програмісти витрачають дуже багато часу, розмірковуючи про продуктивність некритичних фрагментів коду, спроби оптимізувати які негативно позначаються на програмі загалом. З його погляду, не слід звертати увагу на дрібниці, а треба зосередитися саме на критичних місцях, і тільки після того, як ці місця буде точно визначено. Тут я повністю згоден з автором.
Я обстоюю погляд, що оптимізація програми — це сплановані дії, яким приділяється належна увага в процесі розробки всієї системи. Тестування продуктивності має здійснюватися нарівні з функціональним тестуванням, відповідно до вимог до продуктивності системи. Очевидно, що виявлена проблема продуктивності має вищий пріоритет, ніж основні завдання з розробки, для широкого класу застосунків: компʼютерні ігри, аудіо/відео кодеки, системи керування критичними обʼєктами. Виправлення проблеми продуктивності — це і є оптимізація, яку виконано своєчасно, задовго до завершення розробки програми. Своєчасне виправлення таких проблем веде до зниження ризиків проєкту. І навпаки: проблеми, залишені на «потім», призводять лише до зриву строків проєкту й до невиконання вимог щодо продуктивності.
Можна сформулювати такі рекомендації:
-
визначити вимоги до продуктивності (наприклад, скільки кадрів за секунду має показувати гра або скільки часу має займати обробка файла);
-
розробити тести продуктивності відповідно до поставлених вимог (їх можна зробити в межах unit-тестування);
-
тестувати продуктивність нарівні з функціональним тестуванням;
-
при виявленні проблем зосередитися лише на тих фрагментах коду, які дадуть максимальний виграш.
А взагалі, судячи з анотації, статтю присвячено тому, як позбутися оператора go to. Зрозуміло, студенти спеціальності СКС можуть вільно ознайомитися з цією статтею, звʼязавшись зі мною електронною поштою. :)