ottimizzazione prematura e pessimization precoce relativa a standard di codifica C++

Question

di Herb Sutter C++ standard di codifica dice per evitare Premature optimization e Premature pessimization. Ma sento che entrambi stanno facendo la stessa cosa. Quindi mi aspetto qualche aiuto per chiarire questi due concetti con i diversi tra loro. Se vieni con alcuni esempi, sarà più vantaggioso per gli altri. Here è una buona spiegazione su Premature optimization. Ma non sono riuscito a trovarne uno per Premature pessimization

Answer 1

Ciò che intende con pessimizzazione prematura, penso, è esattamente l'opposto dell'ottimizzazione prematura: un fondamentale disprezzo di cui le strutture dati e gli algoritmi da utilizzare.

L'ottimizzazione prematura è spesso interessata da dettagli minuti di algoritmi che possono essere ottimizzati successivamente e non devono essere prestati attenzione all'inizio.

La pessimizzazione prematura, al contrario, riguarda la progettazione di alto livello dell'architettura di codice: un'interfaccia fondamentalmente inefficiente per la libreria, ad esempio, non può essere risolta in seguito ottimizzandola, poiché l'interfaccia pubblica è praticamente scolpita nella pietra.

Answer 2

Preferisco pensare che la premessa pessimizzazione sia semplicemente l'interpretazione errata dei requisiti di prestazione che porta ad una prematura operazione di ottimizzazione. Ad esempio, supponi erroneamente che il tuo codice non funzioni abbastanza velocemente o usi troppe risorse (pessimismo) per ottimizzare dove non è necessario.

Con l'avvento di più e molti set di dati enormi, tendo a vedere invertire più spesso, cioè la mancanza di pessimismo sufficiente che porta alla selezione di algoritmi che non scaleranno per soddisfare le esigenze degli utenti. Questo è spesso associato alla convinzione che l'ottimizzazione del compilatore sia una sorta di sostituto della scarsa selezione dell'algoritmo.

Answer 3

Ci sono scelte sia su piccola che su larga scala da effettuare durante la programmazione.

La pessimizzazione è quando il codice di scrittura in un modo che "impedisce al compilatore di fare un buon lavoro". Un tipico esempio potrebbe essere quello di non posizionare le funzioni in un posto che consenta loro di essere allineati, quando la funzione è VERAMENTE piccola e semplice (ad esempio un {s, g} etter). Questo può far sì che la funzione impieghi 10 volte il tempo necessario, ed è una cosa così semplice da "avere ragione".

Una pessimizzazione che ho trovato alcune volte su questo sito è di usare "a/= 2;" quando "a >> = 1" è ugualmente adatto. Se sappiamo che a non è negativo, allora spostare a sinistra e dividere hanno lo stesso effetto, ma anche quando il compilatore sta ottimizzando la divisione, produce quasi sempre più codice per far fronte alla situazione "potrebbe essere negativa" - e quel codice extra può essere un vero successo in alcuni casi.

L'ottimizzazione prematura si ha quando si srotolano i loop o si rende il codice più complicato semplicemente perché non ci si fida del fatto che il compilatore faccia un buon lavoro, in genere senza prove che non faccia un buon lavoro.

Un altro esempio potrebbe essere "non usare std::vector", ma il tuo expandable array perché "vettore è troppo lento", senza nemmeno aver testato il codice utilizzando std::vector.

Answer 4

Ciò che Herb significa è che quando ci si trova di fronte a due opzioni ugualmente leggibili, scegliere sempre la più efficiente.

Utilizzare std::vector::reserve() o il miglior contenitore standard o l'algoritmo non è l'ottimizzazione prematura. Tuttavia, non utilizzarli sarebbe pessimizzazione prematura.

L'ottimizzazione prematura è quando si sacrifica la leggibilità per motivi di "ottimizzazione" che potrebbe anche non valerne la pena. Usa un profiler per questo.