Ottimizzazione prematura nel decidere come ottimizzare?

In parole semplici:

Ritengo che l'opzione 2 sia un'ottimizzazione prematura.

Alcune delle cose che mi fanno pensare è la giustificazione se vaga:

1. Non spieghi perché è necessario utilizzare il motore di terze parti che menzioni.

2. Hai detto che "senza testarlo, il secondo approccio sarà probabilmente più veloce" . Fai attenzione a non sottovalutare lo sforzo e la complessità del cambiamento. Assicurati di avere una batteria di test unitari.

3. "Dato che stiamo già apportando modifiche" . Semplicemente non fai un'ottimizzazione perché potresti benissimo farlo.

"Il secondo approccio probabilmente eseguirà più rapidamente" è un buon segno di ottimizzazione prematura.

Qualsiasi ottimizzazione dovrebbe essere basata su un'ipotesi seguita da prove (l'ipotesi potrebbe essere sostituita da dati concreti, se presenti). Esempio:

1. Indovina: se uniamo questi due loop in uno, verrà eseguito più velocemente.

2. Prova: la profilazione mostra che l'unione ha permesso di ottimizzare questa porzione di codice del 27,4%.

   Conclusione: dovremmo unire due cicli.

Nel tuo caso, lo schema di prova delle supposizioni sarebbe qualcosa del tipo:

1. Indovina: la seconda soluzione sarebbe più veloce della prima alternativa.

2. Prova: questo benchmark, così come questo e quello, mostrano che la seconda soluzione sarebbe effettivamente più veloce di un fattore da 1,15 a 1,70.

   Conclusione: dati i requisiti attuali, la differenza tra lo sforzo necessario per realizzare la seconda soluzione rispetto al primo e le conseguenze negative attese di ciascuna di quelle alternative sulla qualità del codice, la seconda soluzione dovrebbe essere scelta solo se il fattore di velocità è superiore a 1,45. Prendiamo il rischio?

Tu, d'altra parte, stai immaginando che la seconda soluzione probabilmente sia più veloce, senza alcun dato duro come prova. Significa che può essere più veloce di un fattore di 5.0. O un fattore di 1.005. O un fattore di 0.6, cioè essere più lento.

Basare la tua decisione di ottimizzazione su un'ipotesi piuttosto che su dati precisi è ottimizzazione prematura.

Si noti che non è necessario implementare entrambe le soluzioni e confrontarle: sarebbe troppo costoso. Ma devi comunque raccogliere almeno alcuni dati su una potenziale ottimizzazione in un contesto del linguaggio di programmazione e del compilatore che usi prima di ottimizzare il tuo codice.

• Penso che andrebbe bene includere frutta a sospensione bassa. Cioè, se ci vuole uno sforzo e un numero di linee di codice paragonabili per implementare una soluzione O (n²) e una soluzione O (n), non c'è motivo di non scegliere la migliore delle due.

• Non penso che immergersi in una riscrittura massiva senza una profilazione / valutazione sia una buona idea. Che prove hai che il nuovo approccio sarà più veloce? Hai un prototipo di test o l'esperienza di qualcun altro con il motore di terze parti che menzioni? Puoi passare un giorno o due a chiarire questo, e ottenere alcuni numeri duri?

• Esistono prove concrete del fatto che il pezzo che stai per ottimizzare è un vero e proprio collo di bottiglia ? Di solito il ~ 10% del codice spende ~ 90% dei cicli; se il resto ~ il 90% del codice diventasse due volte più lento, nessuno lo noterebbe. Assicurati di ottimizzare un hotspot effettivo.

Senza i dettagli è difficile saperlo con certezza, ma dalla mia esperienza occasionale nel mantenere componenti di terze parti, preferirei avere il controllo del codice interno piuttosto che fare affidamento sugli altri. Il software di terze parti aggiunge un nuovo livello di complessità amministrativa a un progetto che ha bisogno di una giustificazione migliore di quella che è probabilmente più veloce. Vi consiglio di non integrare software di terze parti a meno che veramente non abbia alternative pratiche.

Mi sembra che il caso non sia dimostrato, quindi segui l'opzione 1.

Questo è ciò che così fanno molte persone - l'approccio "pronto, fuoco, mira". Risolvono un problema prima di sapere se è un problema. Poi, se è stato risparmiato un po 'di tempo, dicono "Vedi, ha funzionato! Possiamo andare avanti adesso?", O se non risparmia molto loro dicono "Bene, dobbiamo provare un'altra ipotesi".

Non investire tempo nel sistemare le cose a meno che tu conosci risparmierai tempo significativo e < em> ecco come lo scopro . Mantieni una mente aperta e lascia che ti dica cosa aggiustare. Sarà probabilmente diverso da quello che avresti indovinato.

Quindi risciacqua e ripeti. Ecco come esegui la seria messa a punto delle prestazioni.