Jakie jest znaczenie zasady optymalizacji programu 90/10?

Według Wikipedii reguła optymalizacji programu 90/10 stwierdza, że ​​„90% czasu wykonania programu spędza się na wykonywaniu 10% kodu” (patrz drugi akapit tutaj ).

Naprawdę tego nie rozumiem. Co to dokładnie znaczy? Jak 90% czasu wykonania można poświęcić tylko na wykonanie 10% kodu? A co z pozostałymi 90% kodu? Jak można je wykonać w zaledwie 10% czasu?

W grze obowiązują dwie podstawowe zasady:

• Niektóre kody są wykonywane znacznie częściej niż inne. Na przykład niektóre kody obsługi błędów mogą nigdy nie zostać użyte. Część kodu zostanie wykonana dopiero po uruchomieniu programu. Inny kod będzie wykonywany w kółko podczas działania programu.
• Niektóre kody działają znacznie dłużej niż inne. Na przykład pojedynczy wiersz, który uruchamia zapytanie w bazie danych lub pobiera plik z Internetu, prawdopodobnie zajmie więcej niż miliony operacji matematycznych.

Reguła 90/10 nie jest dosłownie prawdą. Różni się w zależności od programu (i wątpię, czy istnieją jakieś podstawy do konkretnych liczb 90 i 10; ktoś prawdopodobnie wyciągnął je z powietrza). Ale chodzi o to, że jeśli chcesz, aby Twój program działał szybciej, prawdopodobnie tylko niewielka liczba linii ma znaczenie, aby tak się stało. Identyfikacja wolnych części oprogramowania jest często największą częścią optymalizacji.

Jest to ważny wgląd i oznacza, że ​​decyzje, które wydają się sprzeczne z intuicją nowego dewelopera, często mogą być prawidłowe. Na przykład:

• Jest dużo kodu, że nie warto poświęcać czasu na „ulepszanie” , nawet jeśli robi to w głupi, uproszczony sposób. Czy możesz napisać bardziej wydajny algorytm wyszukiwania dla aplikacji XYZ? Tak, ale tak naprawdę proste porównanie każdej wartości zajmuje trywialny czas, mimo że istnieją tysiące wartości. Więc to po prostu nie jest tego warte. Nowym programistom może być trudno uniknąć niepotrzebnej optymalizacji, ponieważ w ich programie studiów tyle czasu poświęcono na napisanie „poprawnego” (czyli najbardziej wydajnego) algorytmu. Ale w prawdziwym świecie poprawnym algorytmem jest każdy, który działa i działa wystarczająco szybko.
• Zmiany, które powodują, że kod jest znacznie dłuższy i bardziej złożony, mogą nadal przynosić zyski. Na przykład w aplikacji FOO warto dodać setki wierszy nowej logiki, aby uniknąć pojedynczego wywołania bazy danych.

To nie jest prawo natury, ale praktyczna zasada zrodzona z szerokiego doświadczenia. Jest również znany jako reguła 80/20 i jest tylko przybliżeniem.

Pętle, gałęzie i inna kontrola przepływu.

Każde miejsce, które ma if, będzie miało jedną gałąź, która jest podejmowana częściej niż druga gałąź. W ten sposób więcej czasu na wykonanie przeznacza się na tę część programu, a nie na drugą część.

Każde miejsce, które ma pętlę, która działa więcej niż jeden raz, ma kod, który jest wykonywany więcej niż otaczający kod. Dlatego spędza się tam więcej czasu.

Jako przykład rozważ:

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

Tutaj print("Oh No!")będą one działać maksymalnie raz, a często nigdy, podczas gdy DoWork(i)wystąpią około miliona razy.

Pętle

Kusi mnie, aby się tam zatrzymać! :-)

Rozważ ten program

1. do_something

2. loop 10 times
3.    do_another_thing

4.    loop 5 times
5.        do_more_stuff

Linia 1 jest wykonywana raz, podczas gdy linia 3 jest wykonywana 10 razy. Patrząc kolejno na każdą linię

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

Dwie linie odpowiadają za 83% czasu wykonania (przy założeniu, że uruchomienie wszystkich linii zajmuje mniej więcej tyle samo. Zatem 40% programu zajmuje> 80%.

W przypadku większej liczby przykładów z prawdziwego świata wzrasta to, więc tylko niewielka liczba linii stanowi znaczną część czasu pracy.

Reguła 90/10 (lub, jak to się czasem mówi 80/20), jest „praktyczną zasadą” - tylko w przybliżeniu prawdziwą.

Zobacz także zasadę Pareto

Ponieważ pytano tylko o czas wykonania, ten przykład może być pomocny:

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;
}

Mówiąc poważniej, oznacza to, że w prawdziwym kodzie prawie zawsze wywołuje się ciężką funkcję w pętli (zamiast sleep(90);), a przez pozostałe 10% czasu wykonuje się obliczenia jednoprzebiegowe.

Innym przykładem jest obsługa błędów w niektórych usługach HA. Każda wysoce dostępna usługa jest zaprojektowana do pracy przez nieograniczony czas w normalnych warunkach. Działa normalnie przez 99% czasu, ale czasami w przypadku błędu uruchamia obsługę błędów i odzyskiwanie, które mogą być jeszcze bardziej logicznie złożone niż sama usługa.

Rozumowanie 90/10 oznacza, że ​​niewielka część twojego kodu będzie powtarzana lub używana częściej niż inne. Jest to często używane do sugerowania, że ​​powinieneś skoncentrować 90% wysiłków związanych z programowaniem / optymalizacją na 10% kodu.

Pomyśl o zwykłym procesorze tekstu, takim jak Microsoft Word lub OpenOffice :

• Okno dialogowe preferencji nie jest często używane;
• Podprogramy, które rysują znaki, są używane przez cały czas.

To powiedzenie jest również używane w naukach o zarządzaniu ... To jest lekcja życia ... Znaczenie: skoncentruj większość wysiłków tam, gdzie daje to więcej rezultatów.

Wyobraź sobie taki program:

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"

Zauważ, że jest tutaj 11 linii, w których 3 z 11 to pętla for, gdzie ile czasu spędza się na tym raczej małym kawałku kodu? Trochę, podczas gdy pozostałe 8 wierszy drukuje tylko jeden znak. Dlatego strzeż się, że chociaż jakiś kod może być krótki, to nie mówi ci, jak często jest wykonywany i ile czasu to zajmie.

Oprócz zapętlania, jak wspomniano w innych świetnych odpowiedziach, należy również wziąć pod uwagę zasady OSUSZANIA. Dobrze napisany kod zorientowany obiektowo zawiera wiele części wielokrotnego użytku. Te części, które są ponownie używane, z definicji są używane co najmniej dwa razy częściej niż coś, co jest wykonywane tylko raz. Jeśli masz dużo kodu OO, potencjalnie możesz wielokrotnie wykorzystywać kilka klas i metod, a kilka innych fragmentów kodu tylko raz.

Jak wspomniano w innych odpowiedziach, prawdopodobnie lepiej jest poświęcić wysiłek, aby kod, który jest używany częściej, był lepszy niż ulepszanie kodu, który jest używany tylko raz.

To nie jest reguła, to tylko koleś, który zredagował Wikipedię z kilkoma liczbami wyciągniętymi z powietrza i nazwał to regułą. Porównaj z zasadą Pareto, która jest bardziej utrwalona w innych kontekstach. Chciałbym zobaczyć, jakie badania zostały przeprowadzone (jeśli w ogóle) na temat dokładności tej „reguły”.

Ale w zasadzie odpowiedź na twoje pytanie brzmi: niektóre kody są wykonywane znacznie częściej niż inne. Pętle są często tego przyczyną. Innymi przyczynami są czasochłonne połączenia, np. Do zewnętrznych zasobów, takich jak usługi sieciowe lub nośniki danych.

Jest to reinterpretacja „zasady Pareto”, która stwierdza: „w przypadku wielu zdarzeń około 80% skutków pochodzi z 20% przyczyn.”, Znanej również jako zasada 80/20. Ta zasada jest stosowana głównie do ekonomii, więc ma sens, aby była przeznaczona do programowania.

To tylko wzorzec obserwowany przez długi czas.

Oto bardzo fajny film o takich wzorach, a także wyjaśnia zasadę Pareto.

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