Quali sono i vari tratti / tipi di ottimizzazioni premature?

Naviga le tue risposte
2

Per la formazione sulla tecnica di revisione del codice, devo trattare vari argomenti. Uno di questi è l'ottimizzazione prematura. Ho trovato 3 tratti come:

  1. È generalmente malvagio; causando inverso Effetti .
  2. È un dolore non necessario , che causa no guadagnare.
  3. Richiede molto sforzo per raggiungere piccoli vantaggi

C'è qualche altra caratteristica che mi manca? Inoltre, per illustrarli, di solito ottengo dei buoni esempi solo per il 1 ° scenario. Qualcuno può suggerire un esempio solido anche per il secondo e il terzo scenario?

Esempio per il 1 ° scenario:

Using char instead of int for smaller loops to save bytes!

for(char c = 0; c < 20; c++) {} //Evil: Accessing 'char' costlier than 'int'

[Nota: non sono preoccupato del fatto che di solito i compilatori si occupano di cose premature. Questo addestramento è pensato solo per l'illustrazione.]

Questa domanda non riguarda " Quali ottimizzazioni sono premature? "

    
posta iammilind 07.07.2011 - 07:12
fonte

3 risposte

6

Ottimizzazione prematura:

  1. È basato su prestazioni ipotetiche non misurate e
  2. Viene usato come scusa per la progettazione di applicazioni scadenti.

Il primo punto dice che le ottimizzazioni per le prestazioni dovrebbero essere basate su codice profilato, in modo che tu possa concentrarti sugli hot spot e ottenere il massimo dal tuo investimento.

Il secondo punto dice che non dovresti buttare via tutte le ottimizzazioni all'inizio, solo perché pensi che siano premature. Il cosiddetto "male" dell'ottimizzazione prematura non è una scusa per ignorare completamente le prestazioni fino al termine dell'applicazione. Se lo fai, potresti scoprire che il tuo design non scala e dovrai riscriverne parti significative.

La scelta delle strutture dati appropriate per il tuo programma è un esempio di ottimizzazione delle prestazioni iniziali che non è solo auspicabile, ma è necessaria. Un buon design non è mai prematuro.

    
risposta data 07.07.2011 - 07:45
fonte
1

Soprattutto, le ottimizzazioni rendono il codice molto meno leggibile. Ottimizzare quando non c'è bisogno di ottimizzare conta certamente come prematuro. Le ottimizzazioni dovrebbero essere fatte solo quando il codice è fatto e quando ce n'è bisogno. Come regola generale, l'autore dovrebbe essere in grado di motivare perché è stato necessario fare una certa ottimizzazione, e farlo nei commenti del codice sorgente.

Tra le più brutte ottimizzazioni premature troverai le macro funzione, le variabili del file scope dichiarate lì solo per motivi di velocità, i particolari loop offuscati (il conteggio all'indietro è un esempio), spostando tutto il codice in un file h in modo che può essere in linea ecc.

A meno che, naturalmente, l'ottimizzazione non renda il codice meno leggibile. Uno di questi esempi è il passaggio di strutture / oggetti per riferimento anziché per valore. Questa ottimizzazione non rende il codice meno leggibile, perché è incredibilmente comune e non confonderà il lettore. Il lettore tuttavia verrebbe probabilmente a disapprovare se lo hai passato per valore, si aspettano che tu faccia questa ottimizzazione o altrimenti considereranno il tuo programma come scritto male.

    
risposta data 07.07.2011 - 08:32
fonte
1

L'ottimizzazione prematura è spesso:

  • Micro-ottimizzazione . Ottimizzazione al livello più basso. Concentrandosi sui dettagli (irrilevanti) dell'implementazione al costo del design. Per esempio. ottimizzazione del ciclo interno, invece di progettare un algoritmo senza loop.
  • Il codice prima funziona e, quindi, infrange la regola d'oro di: Fallo funzionare. Fallo giusto. Fallo veloce.
  • Cosparsa di frivoli casi speciali
  • Aggiungere entità o concetti senza necessità e quindi violare il rasoio di Occam
risposta data 07.07.2011 - 21:25
fonte

Leggi altre domande sui tag

Definizione di "Stima attività corrente" Creazione della definizione dell'API pubblica per l'applicazione esistente