Quando il codice dovrebbe favorire l'ottimizzazione rispetto alla leggibilità e alla facilità d'uso?

Per rispondere alla domanda per il titolo: quando veramente hai bisogno del guadagno in termini di prestazioni. Sistemi in tempo reale, sistemi embedded o qualcosa del genere. O quando il codice è a un livello molto basso e ci sono astrazioni su strati di astrazione costruiti su di esso. Anche allora preferirei colli di bottiglia provati prima dell'ottimizzazione. Non vincerai molto quando il codice viene chiamato una volta ogni ora. Quando viene chiamato centinaia di volte al secondo, allora c'è un numero.

Since the final product will not necessarily require high performance...

. Sembra che dovresti prima leggere e facilitare l'uso e inserire un commento: "Ottimizza facendo Foo. Forse. Se necessario. Meglio di no."

API == interfaccia

Questo dovrebbe essere il più semplice e intuitivo possibile. È anche totalmente indipendente dall'implementazione.

Implementazione == interno funzionante

Crea un'implementazione pulita, con codice ben strutturato e buone decisioni di progettazione. L'ottimizzazione prematura è la radice del male. Prendi un profiler e controlla dove sono i colli di bottiglia.

Quando crei una libreria o uno strumento che verrà utilizzato da molte persone per scopi diversi, questo è un problema, perché hanno esigenze diverse.

Quello che cerco di fare è ottenere alcuni casi d'uso rappresentativi e assicurarmi che il mio prodotto sia una scelta ragionevole per questi casi, e non è atrocemente cattivo in ogni caso.

Se posso solo dare un esempio di cosa può accadere:

La routine LAPACK DGEMM è una routine generale per moltiplicare le matrici. La sua sequenza chiamante contiene gli argomenti dei caratteri iniziali per specificare determinate opzioni, ad esempio se uno degli argomenti deve essere trasposto.

Gli argomenti di personalizzazione sono lì per due scopi: rendere la programmazione più facile per l'utente e rendere più facile per il writer della biblioteca. Senza di essi, l'utente dovrebbe trasporre gli argomenti da solo o lo scrittore della libreria dovrebbe fornire più routine.

Per gestire questi argomenti, DGEMM chiama una funzione LSAME che confronta i caratteri. Ciò rende anche la vita più semplice per lo scrittore di librerie, perché la rappresentazione dei caratteri può essere molto diversa per alcune macchine.

Lo svantaggio di questo è, se le matrici non sono molto grandi, che DGEMM passa la maggior parte del tempo a chiamare LSAME, rispetto al tempo che spende per moltiplicare le matrici! Se il programma dell'utente impiega molto tempo a chiamare DGEMM, ciò significa che viene speso una notevole quantità di tempo chiamando LSAME, confrontando i caratteri (anche se quei caratteri sono praticamente sempre gli stessi). Lo sforzo ripetuto è uno sforzo inutile. Se un utente riesce a capirlo, ad esempio facendo una pausa casuale, può eseguire routine ad-hoc per moltiplicare le proprie matrici.

Ma il punto più generale è - questo è il problema nella scrittura di librerie o strumenti. Devi cercare di essere utile per uno spettro di esigenze.

Non ottimizzarlo mai se non hai ottime ragioni. C'è così tanto da fare sotto il cofano (ci sono un sacco di oscure ottimizzazioni nel compilatore o anche nella CPU stessa) che è molto difficile sapere quale tipo di impatto avrà l'ottimizzazione. Potresti renderlo più veloce o più lento, non lo saprai mai a meno che non lo indichi.

Inoltre, se la tua applicazione è già abbastanza veloce, perché dovresti preoccuparti di renderla più veloce? È tempo che tu sprechi quando potresti spenderlo rendendo più leggibile il tuo codice.