У чому сенс правила 90/10 оптимізації програми?

Згідно з Вікіпедією, правило 90/10 для оптимізації програми зазначає, що "90% часу на виконання програми витрачається на виконання 10% коду" (див. Другий параграф тут ).

Я справді цього не розумію. Що саме це означає? Як 90% часу на виконання може бути витрачено лише на виконання 10% коду? А як тоді з іншими 90% коду? Як їх можна виконати лише за 10% часу?

Тут грають два основні принципи:

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

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

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

• Існує безліч коду, що не варто витрачати свій час на те, щоб зробити "кращим" , навіть якщо він робить речі німим, спрощеним способом. Чи можете ви написати більш ефективний алгоритм пошуку для програми XYZ? Так, але насправді просте порівняння кожної величини займає тривіальну кількість часу, навіть якщо є тисячі значень. Тож просто не варто. Новим розробникам може бути важко уникнути зайвої оптимізації, оскільки в їхній програмі ступеня стільки часу було витрачено на написання «правильного» (мається на увазі найбільш ефективного) алгоритму. Але в реальному світі правильним алгоритмом є будь-який, який працює і працює досить швидко.
• Зміни, які роблять ваш код набагато довшим і складнішим, все одно можуть бути виграшними показниками. Наприклад, у програму FOO можливо, варто додати сотні рядків нової логіки, просто щоб уникнути єдиного виклику бази даних.

Це не закон природи, а правило, народжене великим досвідом. Це також відоме як правило 80/20 і є лише колись приблизним наближенням.

Петлі, гілки та інше управління потоком.

У кожному місці, яке має if, у вас буде одна гілка, яка береться частіше, ніж інша гілка. Таким чином, більше часу на виконання витрачається на виконання тієї частини програми, а не іншої частини.

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

Як приклад розглянемо:

def DoSomeWork():
    for i in range(1000000):
        DoWork(i)
    except WorkExeption:
        print("Oh No!")

Тут print("Oh No!")воля буде виконуватись максимум один раз, а часто ніколи, тоді як DoWork(i)воля відбудеться приблизно мільйон разів.

Петлі.

Я спокусився зупинитися на цьому! :-)

Розглянемо цю програму

1. do_something

2. loop 10 times
3.    do_another_thing

4.    loop 5 times
5.        do_more_stuff

Рядок 1 виконується один раз, а рядок 3 - 10 разів. Дивлячись по черзі на кожен рядок

1 1   0.8%
2 10  8.3%
3 10  8.3%
4 50 41.3%
5 50 41.3%

На два рядки припадає 83% часу виконання (якщо запустити, що всі рядки займають приблизно однаковий час. Отже, 40% програми займає> 80%.

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

Правило 90/10 (або як це іноді ставиться 80/20) - це "велике правило" - лише приблизно так.

Див. Також Принцип Парето

Коли ви запитували лише про час виконання, цей приклад може бути корисним:

int main() {
    sleep(90); // approximately 10% of the program.
    // other 90% of the program:
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    return 0;
}

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

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

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

Подумайте про звичайний текстовий процесор, як-от Microsoft Word або OpenOffice :

• Діалог налаштувань використовується мало;
• Підпрограми, які малюють символи, використовуються постійно.

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

Уявіть собі таку програму:

print "H"
print "e"
print "l"
print "l"
print "o"
for i=0 to 1,000,000
    print "How long now?"
next
print "B"
print "y"
print "e"

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

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

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

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

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

Це переосмислення "принципу Парето", який стверджує, що "для багатьох подій приблизно 80% наслідків походять від 20% причин". Також відоме як правило 80/20. Це правило в основному застосовується до економіки, тому має сенс, що воно буде призначене для програмування.

Це просто закономірність, яку спостерігали протягом тривалого періоду часу.

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

https://www.youtube.com/watch?v=fCn8zs912OE&ab_channel=Vsauce