Domanda riguardante la leggibilità rispetto al tempo di elaborazione

Sacrificare la leggibilità del codice per risparmiare alcuni cicli di clock è un chiaro segnale di ottimizzazione prematura.

Il tuo primo obiettivo dovrebbe essere sempre quello di scrivere il codice più leggibile / manutenibile che dia prestazioni ragionevoli. Solo dopo che le misurazioni hanno indicato che i test N condition rappresentano effettivamente un collo di bottiglia per le prestazioni complessive e non ci sono ottimizzazioni possibili che potrebbero produrre un effetto più ampio (come l'utilizzo di un algoritmo diverso), quindi potresti prendere in considerazione la possibilità di sacrificare la leggibilità per ottenere le prestazioni richieste.

Anche se ti trovi nella situazione estremamente rara che stai scrivendo una libreria che deve sempre dare le massime prestazioni, dovresti considerare attentamente se la perdita di leggibilità vale poche istruzioni e se un buon compilatore di ottimizzazione non genererebbe lo stesso codice per entrambi comunque.

And let's assume that checking a condition is 1 clock long and performing a step doesn't take up time.

No.

Non facciamo supposizioni che distorcano completamente la discussione. In realtà, i passaggi richiedono tempo, molto probabilmente molto più tempo rispetto a tutte le condizioni di controllo.

Il che significa che le considerazioni sulle prestazioni sono irrilevanti .

E questo è il motivo per cui l'ottimizzazione prematura è, in effetti, un cattivo anche quando le prestazioni sono molto importanti .

I compilatori di solito tagliano e tagliano e ricostruiscono completamente qualsiasi codice che compilano. Poiché il codice leggibile è più comune, le ottimizzazioni di solito sono ottimizzate per questo, in modo che il codice leggibile abbia effettivamente maggiori possibilità di essere ottimizzato dal compilatore.

Nota a margine, evita di tornare per riferimento. È più difficile da leggere e più difficile da ottimizzare per il compilatore. La variabile dovrebbe sempre essere impostata come _no_error = _no_error && step_one() (che, accidentalmente, agisce come condizione, quindi non ne hai bisogno, ma non è in linguaggio C ++ )

Infine, non considero molto più leggibile la _no_error (oltre al brutto nome di quella variabile, i simboli che iniziano con _ sono riservati per le estensioni della libreria). Un codice leggibile in qualsiasi linguaggio che supporti RAII (C ++, D, Rust) o equivalente (finalmente) (C #, Java) è:

if(!step_one())
    return;
if(!step_two())
    return;
...

Nella semplice vecchia C, è preferibile usare goto , se hai bisogno di una ripulitura, altrimenti puoi ovviamente usare anche return direttamente:

if(!step_one())
    goto failed;
if(!step_two())
    goto failed;
...
failed:
clean_up();

Se dici esattamente e concisamente ciò che desideri, il compilatore può produrre il codice più efficiente. Quasi tutte le semplici ottimizzazioni che facevamo a mano sono ora eseguite automaticamente dai compilatori.

Non hai bisogno di una variabile di stato. Ogni funzione restituisce true in caso di successo e false in caso di errore, quindi scrivi:

if (step_one()
    && step_two()
    && step_three()
    && ...) {
  /* success */
  ...
} else {
  /* failure */
  ...
}
...

Nella maggior parte dei linguaggi di programmazione imperativi, (C, Java, C #, Python, Perl, Ruby, LISP, ecc.) l'operatore e ( && o and ) valuta le clausole da sinistra a destra e si ferma non appena uno è falso.

Se hai molti passaggi e devi uscire non appena si fallisce, prendi in considerazione la possibilità di mettere i puntatori di funzione in un array ed eseguirli tutti, come questo:

// The array
int (*steps[2]) ();

// Assign functions
steps[0] = step_one;
steps[1] = step_two;

// Call them
for (int i = 0; i < 2; i++) {
     if (!(*steps[i])()) 
         break;
}

Questo approccio ti consente di configurare durante il tempo di esecuzione in quale ordine devi eseguirli.