Qual è il significato della regola di ottimizzazione del programma 90/10?

Secondo Wikipedia, la regola del 90/10 dell'ottimizzazione del programma afferma che "il 90% del tempo di esecuzione di un programma viene impiegato nell'esecuzione del 10% del codice" (vedere il secondo paragrafo qui ).

Davvero non lo capisco. Cosa significa esattamente? Come si può impiegare il 90% del tempo di esecuzione solo eseguendo il 10% del codice? Che dire poi dell'altro 90% del codice? Come possono essere eseguiti solo nel 10% delle volte?

Ci sono due principi di base in gioco qui:

• Alcuni codici vengono eseguiti molto più spesso di altri codici. Ad esempio, alcuni codici di gestione degli errori potrebbero non essere mai utilizzati. Alcuni codici verranno eseguiti solo all'avvio del programma. Altro codice verrà eseguito più volte durante l'esecuzione del programma.
• L' esecuzione di alcuni codici richiede molto più tempo rispetto ad altri codici. Ad esempio, una singola riga che esegue una query su un database o estrae un file da Internet richiederà probabilmente più di milioni di operazioni matematiche.

La regola del 90/10 non è letteralmente vera. Varia in base al programma (e dubito che ci sia qualche base per i numeri specifici 90 e 10; qualcuno probabilmente li ha tirati fuori dal nulla). Ma il punto è che se hai bisogno che il tuo programma funzioni più velocemente, probabilmente solo un piccolo numero di righe è significativo per farlo accadere. L'identificazione delle parti lente del software è spesso la parte più grande dell'ottimizzazione.

Questa è una visione importante e significa che le decisioni che sembrano controintuitive per un nuovo sviluppatore possono spesso essere corrette. Per esempio:

• C'è un sacco di codice che non vale la pena dedicare del tempo a "migliorare" , anche se sta facendo le cose in modo stupido e semplicistico. Potresti scrivere un algoritmo di ricerca più efficiente per l'applicazione XYZ? Sì, ma in realtà un semplice confronto di ogni valore richiede una banale quantità di tempo, anche se ci sono migliaia di valori. Quindi non ne vale la pena. Può essere difficile per i nuovi sviluppatori evitare l'ottimizzazione non necessaria, perché nel loro corso di laurea è stato dedicato molto tempo alla stesura dell'algoritmo "corretto" (che significa più efficiente). Ma nel mondo reale, l'algoritmo corretto è quello che funziona e funziona abbastanza velocemente.
• Le modifiche che rendono il codice molto più lungo e più complesso possono comunque essere una vittoria delle prestazioni. Ad esempio, nell'applicazione FOO può valere la pena aggiungere centinaia di righe di nuova logica, solo per evitare una singola chiamata al database.

Questa non è una legge della natura, ma una regola empirica nata da una vasta esperienza. È anche conosciuta come la regola 80/20 ed è sempre e solo una approssimazione approssimativa.

Loop, rami e altri controlli di flusso.

Ogni posto che ha un if, avrai un ramo che viene preso più spesso dell'altro ramo. Pertanto, si impiega più tempo per l'esecuzione di quella parte del programma e non l'altra parte.

Ogni posto che ha un ciclo che gira più di una volta, hai un codice che viene eseguito più del codice circostante. Quindi più tempo viene trascorso lì.

Ad esempio, considera:

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

Qui il test print("Oh No!")verrà eseguito solo una volta al massimo, e spesso mai, mentre DoWork(i)si verificherà circa un milione di volte.

Loops.

Sono tentato di fermarmi qui! :-)

Considera questo programma

1. do_something

2. loop 10 times
3.    do_another_thing

4.    loop 5 times
5.        do_more_stuff

La riga 1 viene eseguita una volta mentre la riga 3 viene eseguita 10 volte. Guardando ogni riga a turno

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

Due righe rappresentano l'83% del tempo di esecuzione (supponendo che tutte le righe richiedano lo stesso tempo per l'esecuzione. Pertanto, il 40% del programma richiede> 80%.

Con esempi più ampi del mondo reale questo aumenta, quindi solo una piccola quantità di righe rappresenta gran parte del tempo di esecuzione.

La regola 90/10 (o come viene talvolta definita 80/20) è una "regola empirica" ​​- solo approssimativamente vera.

Vedi anche Principio di Pareto

Come è stato chiesto solo del tempo di esecuzione, questo esempio potrebbe essere utile:

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

Se essere un po 'più serio, significa che nel codice della vita reale quasi sempre si chiama una funzione pesante in un ciclo (anziché sleep(90);), mentre il resto del 10% delle volte si eseguono calcoli a passaggio singolo.

Un altro esempio è la gestione degli errori in alcuni servizi HA. Qualsiasi servizio a disponibilità elevata è progettato per funzionare per un tempo infinito in condizioni normali. Funziona normalmente il 99% delle volte, ma occasionalmente, in caso di errore, esegue una gestione e un recupero degli errori, che possono essere persino più logicamente complessi del servizio stesso.

Il ragionamento 90/10 significa che una piccola parte del tuo codice verrà ripetuta o utilizzata più di altre. Questo è spesso usato per suggerire che dovresti concentrare il 90% del tuo sforzo di sviluppo / ottimizzazione in questo 10% del tuo codice.

Pensa a un normale elaboratore di testi, come Microsoft Word o OpenOffice :

• La finestra di dialogo delle preferenze non è molto usata;
• Le subroutine che disegnano i personaggi vengono usate continuamente.

Questo detto è usato anche nelle scienze gestionali ... Questa è una lezione per la vita stessa ... Significato: concentra la maggior parte dei tuoi sforzi dove ti dà più risultati.

Immagina un programma come questo:

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"

Notate come ci sono 11 righe qui dove 3 su 11 sono il ciclo for, dove quanto tempo viene impiegato su questo pezzo di codice piuttosto piccolo? Abbastanza un po 'mentre le altre 8 righe stanno semplicemente stampando un singolo carattere. Quindi, attenzione che mentre un po 'di codice può essere breve, ciò non ti dice quanto spesso viene eseguito e quanto tempo ci vorrà.

Oltre al looping, come menzionato da altre grandi risposte, ci sono anche principi DRY da considerare. Ben scritto, il codice orientato agli oggetti ha molte parti riutilizzabili. Quelle parti che vengono riutilizzate, per definizione, vengono utilizzate almeno due volte più spesso di qualcosa che viene eseguito una sola volta. Se disponi di molto codice OO, potresti riutilizzare alcune classi e metodi molte volte e qualche altra parte di codice una sola volta.

Come menzionato in altre risposte, è probabilmente meglio dedicare uno sforzo per rendere il codice che viene usato più spesso meglio che migliorare il codice che viene utilizzato solo una volta.

Non è una regola, è solo un tipo che ha modificato Wikipedia con un paio di numeri tirati fuori dal nulla e l'ha definita una regola. Confronta con il principio di Pareto, che è più saldamente stabilito in altri contesti. Mi piacerebbe vedere quali ricerche sono state fatte (se presenti) sull'accuratezza di questa "regola".

Ma sostanzialmente la risposta alla tua domanda è che alcuni codici vengono eseguiti molto più frequentemente di altri codici. I loop sono spesso la ragione di ciò. Altri motivi sono le chiamate che richiedono tempo, ad esempio a risorse esterne come servizi Web o supporti di archiviazione.

È una reinterpretazione del "principio di Pareto", che afferma "per molti eventi, circa l'80% degli effetti deriva dal 20% delle cause", noto anche come regola 80/20. Questa regola si applica principalmente all'economia, quindi ha senso che venga riproposta per la programmazione.

È solo uno schema che è stato osservato per un lungo periodo di tempo.

Ecco un video molto bello su modelli come questo, e spiega anche il principio di Pareto.

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