A che punto si dovrebbe iniziare a pensare alle prestazioni?

Il differimento delle considerazioni sulle prestazioni a volte si basa su una errata applicazione della frase:

Premature optimization is the root of all evil.

Se leggete la citazione completa, ciò che Knuth stava cercando di dire è che le micro-ottimizzazioni applicate durante lo sviluppo senza profilazione sono generalmente sconsigliabili, perché portano a un codice meno gestibile senza necessariamente ottenere sostanziali benefici in termini di prestazioni.

Ma ciò non significa che non dovresti prendere in considerazione le prestazioni finché l'applicazione non è quasi terminata. Se lo fai, potresti scoprire che le prestazioni sono inadeguate, la tua architettura di progettazione non supporta prestazioni migliori e devi ricominciare da capo.

Ci sono un certo numero di cose che puoi fare durante lo sviluppo per ottenere buone prestazioni, senza ottimizzazioni esoteriche (e premature):

1. Utilizza un'architettura ragionevole e ben ponderata.
2. Utilizza le strutture dati in modo appropriato.
3. Utilizza tecnologie (librerie, framework) che funzionano in modo adeguato.

Se fai queste cose, scoprirai che qualsiasi ottimizzazione delle prestazioni che deve verificarsi sarà limitata a una piccola parte del tuo codice. Il profiling identificherà quel codice e ti permetterà di focalizzare i tuoi miglioramenti delle prestazioni dove faranno il massimo, senza sacrificare la manutenibilità.

Ecco cosa NON DEVE pensare:

• È ++i più veloce di i++ ?
• È switch più veloce di if ?
• Dovrei inline le mie funzioni?
• Le funzioni virtuali sono lente?
• C ++ / Java / C # è più veloce / più lento dell'altro?
• blah, blah, ...

Ecco a cosa pensare:

• Cos'è un carico di lavoro previsto realistico?
• Quante volte cambiano le informazioni di input e chi le fornisce? Ha senso considerare la precompilazione?
• Ho mantenuto la mia struttura dati il più semplice e il più possibile normalizzata? Ciò significa non preoccuparsi dell'hashing e cose del genere.
• Ho mantenuto notifiche al minimo assoluto? (Ecco dove le modifiche in una parte dei dati richiedono modifiche in una stessa fase in un'altra parte, perché la struttura dei dati non è normalizzata.)

Riguardo a quest'ultimo punto, nella mia esperienza è meglio progettare la struttura dei dati in modo che, se deve essere non normalizzata, sia in grado di tollerare l'incoerenza temporanea, che può essere successivamente risolta con una sorta di scansione periodica . Un grande killer di prestazioni è quando le notifiche attivano ulteriori notifiche, che si innescano ulteriormente, in una misura che non avresti mai immaginato prima. E spesso è uno sforzo inutile a causa delle modifiche che si annullano automaticamente.

Se hai fatto tutto questo, hai un design pulito. Poi periodicamente mentre lo sviluppi, profilo. ( Pausa casuale è il metodo su cui mi baso.) Quindi, se vedi che le prestazioni potrebbero essere migliorate introducendo un algoritmo più sofisticato, fallo assolutamente.

No dovresti pensare alle prestazioni (specialmente nella progettazione di database) dall'inizio. Ci sono stati molti danni al nostro settore da parte di persone che pensano che l'ottimizzazione sia l'ottimizzazione prematura. La citazione era originariamente intesa a impedire alle persone di guardare a micro-ottimizzazioni prima che si verificasse un problema. Non era destinato a non fare alcuna ottimizzazione. Ad esempio, in un database ci sono molte tecniche conosciute che funzionano male. Evitare quelli, nel design, è parte di ciò che devi fare. È molto difficile effettuare il refactoring di un database con 100.000.000 di record perché è stato progettato utilizzando tecniche di perforazione insufficiente e non possiamo più evitare il problema acquistando un hardware migliore.

Preoccupati della correttezza ¹ prima, poi della manutenibilità, poi della sicurezza e dell'affidabilità, e poi puoi pensare alle prestazioni. Applica questo ordine a ciascun pezzo di codice mentre lo stai sviluppando. È possibile che una soluzione performante possa naturalmente uscire semplicemente mantenendo le cose chiare e dirette.

L'80% delle prestazioni sta scegliendo il giusto algoritmo e la struttura dei dati per il problema in questione; un quicksoft poco ottimizzato sta ancora andando a battere i pantaloni di un tipo di bolla altamente ottimizzato nel caso medio (nel caso peggiore è un pareggio).

Ciò che tutti su SO stanno cercando di schiacciare è la mentalità "che è più veloce, ++ p o p ++", in cui le persone sono così coinvolte nel furto del compilatore che perdono traccia del problema più grande, con conseguente codice che è fragile, infestato da bug, sbagliato e, soprattutto, non molto più rapidamente di quanto sarebbe stata una soluzione più semplice. Ho affrontato questo tipo di codice di prima mano; un esempio è stato così fragile che non siamo riusciti a modificare nessun senza romperlo completamente.

¹ Dove "correttezza" significa "soddisfare le specifiche", che non è sinonimo di "senza bug".

Dovresti iniziare a pensare alle prestazioni una volta che sai qual è la performance "buona". In altre parole, sarebbe sbagliato iniziare a pensare alle prestazioni prima di aver identificato quali sono le seguenti soglie:

• Prestazioni inaccettabili - risolvilo ora prima che diventi più sfavorevole
• Prestazioni accettabili: è ora di concentrarsi su altre funzionalità prima di tentare di fare altro con le prestazioni.
• Prestazioni target: numeri di prestazioni idealizzati. Cioè se hai tempo e risorse sufficienti, cosa ti serve il tuo sistema?

Una volta identificati quali sono queste soglie, hai anche identificato la metrica che stai utilizzando per misurare le prestazioni. Ciò significa che è possibile impostare alcuni test delle prestazioni automatizzati che è possibile eseguire più volte al giorno. Questo ti dirà se stai migliorando o peggiorando.

Per elaborare queste metriche, devi capire che cosa deve fare il tuo sistema. Ad esempio, sono richieste metriche di prestazioni assolute (risposta entro il tempo X) o sono richieste misurazioni del throughput (X risposte per ora Y)? La velocità effettiva e l'ottimizzazione del tempo assoluto richiedono approcci diversi e, se non sai cosa è veramente importante, potresti ottimizzare la strada sbagliata.

Probabilmente hai sentito che l'ottimizzazione prematura è la radice di tutti i mali. La domanda è cosa lo rende prematuro? A mio parere, non è mai una cattiva idea pensare alle prestazioni, ma non preoccuparti eccessivamente finché il tuo codice non funziona. Una volta che funziona, esegui alcuni test di carico pesante, profila e identifica i colli di bottiglia e ottimizza le prestazioni.

Detto questo, non c'è niente di sbagliato nel pensare alle prestazioni durante la fase iniziale della codifica se si conoscono determinate tecniche che faranno davvero la differenza. Ad esempio, scegliere una struttura di archiviazione da una libreria piuttosto che un'altra, poiché l'esperienza passata ti ha insegnato che una di esse è più veloce / utilizza meno RAM rispetto all'altra. O costruire in un semplice (puoi renderlo più sofisticato se il test successivo lo richiede) il caching system per i dati che conosci saranno accessibili molto e sarebbe molto meglio memorizzato nella cache . In questo modo, non ti preoccupi troppo delle prestazioni (almeno non all'inizio) ma stai usando suggerimenti e trucchi che hai appreso durante il percorso da altri progetti. Cerca di mantenerli semplici in modo che siano facili da includere durante lo sviluppo iniziale e potrebbero offrire anche dei vantaggi.

Le prestazioni dovrebbero essere dettagliate nel sistema e nelle specifiche relative all'utente del documento dei requisiti. So che molte persone sghignazzano all'idea di intraprendere Analisi dei requisiti nello sviluppo di un'applicazione, ma sorprendentemente tale documento sarà conciso rispondi a cosa e dove dovresti dedicare le tue risorse relative alle prestazioni all'avvicinarsi dell'applicazione. E risponderà a questa domanda in modo tempestivo

Requisiti La documentazione consente di risparmiare centinaia di ore che altrimenti andrebbero sprecate in processi non essenziali.

Un approccio equilibrato sarebbe meglio. Le prestazioni sono importanti ma non così importanti come fare le cose, quindi:

1. prima costruisci una funzione cercando di riflettere un po 'su ciò che fai e su come lo fai (usa un po' di tempo a pensare alle prestazioni ma non molto)
2. Provalo
3. una volta inizia a pensare se c'è un reale bisogno di migliorarlo (generalmente non lo farai, ma in alcuni casi potresti farlo).

Questo è il mio approccio comune a performace vs funzionalità, e in generale tutto dipende da cosa fa il programma e verificare se c'è bisogno di far funzionare le cose meglio e quanto tempo mi costerebbe.

Pensiamo a un Q & Un sito web come questo, penso che quelli dietro di esso sicuramente pensassero molto su come rendere l'Asking una domanda e ottenere la risposta il più tempo / costo perfomant possibile. Tuttavia, quando pensi alle notifiche, non importa molto se le notifiche vengono visualizzate ogni tanto e ti dicono che c'è una nuova risposta o qualcosa del genere.

Esiste un modo per rinviare il pensiero in modo sicuro alle prestazioni: utilizzando i linguaggi specifici del dominio, ove possibile.

Se la maggior parte del tuo sviluppo può essere fatto con i tuoi piccoli DSL, e sono progettati abbastanza bene per esprimere il tuo dominio problematico nella forma più generica e di alto livello, è possibile ottenere un prototipo funzionante prima, senza sempre pensando alle prestazioni e quindi solo migliorare le implementazioni DSL, non il vero codice del dominio del problema.

È un approccio molto migliore anche dal punto di vista della manutenibilità.

Devi prendere in considerazione le prestazioni. Tuttavia, devi tracciare una linea per contrassegnare la fine della sintonizzazione, poiché (di solito) il tuo tempo è più importante di quello del computer.

Un ottimo articolo di testo sul rendimento è: The Computer Performance Shell Gioco .

The computer performance shell game, also known as "find the bottleneck", is always played between these four resources:

• CPU
• Disk
• Network
• Memory

At any given moment, your computer is waiting for some operation to complete on one of these resources. But which one: CPU, memory, disk, or network? If you're interested in performance, the absolute first thing you have to do is determine which of these bottlenecks is currently impeding performance -- and eliminate it.

Il modo "migliore" è un termine molto carico e la risposta potrebbe dipendere in gran parte da fattori sconosciuti fino al runtime.

• Hai un sacco di memoria? - Otterrai prestazioni migliori con una struttura dati "all-in-memory", ma se non hai abbastanza memoria sostituirà le tue prestazioni.
• Hai bisogno di persistenza? Un database fornisce l'integrità ma è più lento della precedente struttura di dati "all-in-memory". MUCH più lento.
• Puoi memorizzare i risultati nella cache? La vernice può aiutarti! link

L'elenco potrebbe continuare all'infinito.

Quello che puoi fare, è scrivere "la cosa più semplice che potrebbe funzionare" dalla conoscenza che hai do attualmente, e farlo in un modulari moda in modo da poter riorganizzare facilmente quando ne sai di più. Nota che la cosa "più semplice" non è necessariamente semplice!

È sempre qualcosa che dovresti tenere a mente. Penso che quello che la maggior parte delle persone sta cercando di dire è che non ha molto senso passare due giorni a cercare di ottimizzare qualcosa che non si sa nemmeno se è rotto. Una volta che un prodotto è in esecuzione e può eseguire alcuni test di usabilità, questo dovrebbe mostrare dove si verificano problemi di prestazioni. Quindi, una volta identificati i veri problemi di prestazioni, puoi scegliere come target le ottimizzazioni che devi eseguire.

In teoria, almeno, dovresti iniziare a pensare alle prestazioni dopo aver fatto il beta test e non prima.

Questa non è, tuttavia, la licenza per prendere decisioni di design scadenti. Ad esempio, l'utilizzo di una stringa NVARCHAR come chiave primaria è un percorso sicuro verso prestazioni scadenti; Detto questo, è un'abitudine sporca, a prescindere dai problemi di prestazioni e non dovresti utilizzarla in primo luogo.

Se il tuo progetto segue le best practice convenzionali (tutto nella 3a forma normale, l'occultamento corretto delle informazioni nelle tue classi, l'uso minimo di singleton, ecc.) e c'è un problema di prestazioni in seguito, sarà facile da gestire (creare un indice qui, implementa una cache lì).

HTH

Dipende. È utile tenere a mente la regola 80/20: la maggior parte (diciamo 80%) del codice nell'applicazione non verrà mai eseguita abbastanza spesso da fare alcuna differenza notevole nelle prestazioni. Devi concentrarti sul restante 20% in cui l'app è destinata a spendere circa l'80% del tempo di esecuzione.

Potresti riuscire a identificare alcuni degli ovvi punti caldi delle prestazioni in anticipo, ad esempio se sai che un determinato calcolo verrà ripetuto milioni di volte. In questi casi vale la pena pensare di ottimizzarlo in anticipo scegliendo le giuste strutture dati e gli algoritmi per il lavoro.

Tuttavia, questa ottimizzazione è più un'attività di progettazione. Ciò che di solito non vale niente sono le micro-ottimizzazioni, in cui qualcuno passa una quantità eccessiva di tempo con astuti trucchetti nel nome del "guadagnare prestazioni". Soprattutto se fatto senza misurazioni appropriate prima e dopo, tali cambiamenti potrebbero non fare alcuna differenza, o in realtà rallentare l'app in circostanze di vita reale.

Dipende dalla fase di sviluppo in cui ti trovi

1) Se costruisci funzionalità del tuo software, mantienilo attivo e assicurati che funzioni correttamente (cioè, desiderato ed efficiente).

2) Una volta integrati i building block, otterrai un suggerimento di risorse hogger, in questo modo avrai spazio per l'ottimizzazione.

Se devi iniziare a pensare al rendimento, sei nei guai. Dovresti pensare alle prestazioni tutto il tempo. In effetti, sospetto che i bravi programmatori penseranno alle prestazioni anche quando non intendevano farlo, in un «uomo che pensa al sesso ogni sette secondi» alla moda ...

Ciò che è importante è quali azioni prenderai in base a tutto ciò che pensi. I pensieri sono economici, ma le azioni possono infrangere il codice e far saltare le scadenze.

La maggior parte delle volte, l'unica azione sensata è quella di non fare nulla: hai identificato che il tuo codice non verrà chiamato abbastanza spesso perché i problemi di performance siano osservabili, forse è un pezzo di codice di avvio che viene eseguito una volta per computer per l'1% della tua potenziale base di utenti, forse è un po 'di codice server ridondante annegato in un mare di accessi al database lenti, forse è solo un numero intero in una sezione di codice non critica.

Molto spesso, si sospetta che una determinata operazione potrebbe causare un problema di prestazioni che potrebbe essere risolto con una semplice modifica. C'è, ad esempio, la sensazione fastidiosa che l'esecuzione di una query SQL complessa su ogni richiesta, o la richiesta dello stesso pezzo di dati da un dizionario due volte, sia dannosa per te. È qui che la conoscenza delle tecniche di ottimizzazione è utile e forse la conclusione più sorprendente è la seguente:

Se conosci una tecnica rapida che quasi certamente migliorerà le prestazioni di un pezzo di codice, non farlo.

Se riesci a pensarci subito, puoi farlo sicuramente dopo cinque minuti. Mantenerlo fuori dal codice (ma, forse, in un commento // TODO ) lascia il pulitore del codice e ti risparmia la volta precedente per lavorare su un'altra funzione, senza perdere tempo se finisci per gettare via quel codice in seguito. Se il codice originale risulta causare problemi di prestazioni durante il test, tornare indietro e applicare la tecnica rapida.

Non sto dicendo che dovresti evitare di scrivere codice che è idiomatico solo perché sembra essere più veloce. Scrivi codice idiomatico in base alle migliori pratiche che migliorano la produttività e la leggibilità e riducono i bug. È solo che, se hai una scelta tra codice idiomatico da libro e un'alternativa più veloce ma facilmente scritta, scegli sempre la leggibilità anziché la velocità.

L'unica situazione difficile è quando non sembra esserci un modo semplice per migliorare le prestazioni del codice, eppure è dolorosamente ovvio che un pezzo di codice si romperà non appena viene consegnato: un attraversamento completo del database ad ogni clic, un centinaia di richieste SQL per pagina sul sito o qualcosa di altrettanto terribile. Qui è dove devi fermarti e pensare di più. Questi sono in genere problemi di architettura che non possono essere risolti su scala locale. Conferma i tuoi sospetti con un rapido picco o un prototipo, cerca esperienze simili e soluzioni comuni e considera un cambiamento di architettura o una riduzione delle funzionalità.

IMHO è importante pensare alle prestazioni prima di implementare il sistema, ma solo a pensarci. Dovresti analizzare l'applicazione e scoprire quali potrebbero essere potenziali colli di bottiglia nelle prestazioni.

Quindi implementa il sistema il più semplice possibile. Se sorgono problemi di prestazioni, quindi ottimizzare.

Ad esempio, supponiamo di avere un client GUI che riceve i dati attraverso un tipo di servizio (SOAP, REST HTTP, ecc.). Quindi la cosa più importante per le alte prestazioni / scalabilità è avere il minor numero possibile di chiamate, poiché ogni chiamata restituisce molti dati, piuttosto che molte chiamate restituiscono un po 'di informazioni ciascuna, ovvero preferiscono una comunicazione spessa al loquace.

Quando si implementa questo tipo di sistema, non mi interessa molto del numero di chiamate tra il sistema. Ma farei in modo che il codice base mi renda più semplice il refactoring / l'ottimizzazione quando si presentano i bisogni.

Dovresti pensare alle prestazioni in modo molto generale fin dall'inizio. Dovresti selezionare strutture dati e algoritmi che funzioneranno bene per la tua applicazione ed essere ragionevolmente efficienti. Gli algoritmi sono fondamentali per il software e le strutture dei dati più. Probabilmente dovrai eseguire le riscritture più importanti se devi apportare importanti modifiche a entrambi, mentre i dettagli più piccoli possono essere riscritti più facilmente.

Potresti anche voler ottenere abitudini efficienti, ma queste dipenderanno dalla lingua. In C ++, ad esempio, "++ i;" come una dichiarazione o un'espressione stand-alone è sempre almeno buono come "i ++;", e potrebbe potenzialmente essere molto più efficiente. Nella maggior parte dei casi, però, dovresti scrivere codice chiaro e fidarti del compilatore. Prendere l'abitudine di preoccuparsi delle micro-efficienze causerà quasi certamente più problemi di quanti ne risolva. Per le app desktop, il compilatore è almeno intelligente quanto lo sei su i >> 1 rispetto a i / 2 , oppure il modo migliore per migliorare le prestazioni è ottenere un compilatore migliore, quindi non preoccuparti.

Oltre a questo, non ti preoccupare molto finché non hai qualcosa che puoi testare. A quel punto, puoi profilare il programma per vedere dove sono i punti caldi e probabilmente avere un'idea se hai un programma di prestazioni o meno. Se hai bisogno di migliorare le prestazioni, trova dove il programma spende la maggior parte del suo tempo e migliora le cose lì. Se hai progettato un'adeguata efficienza globale e hai scritto bene il programma, stai cambiando solo una parte relativamente piccola del programma.

Penso che il meglio che puoi fare sia seguire le buone pratiche di progettazione (ad es., non fare cose che sai ostacoleranno le prestazioni) finché non inizi a lavorare. Se non puoi misurare il miglioramento, non puoi migliorare. Una volta che hai qualcosa su cui puoi fare dei test, allora è spesso una buona idea fare una corsa di profilazione e avere un'idea di dove sono i punti caldi (se ce ne sono). Se qualcosa ti salta fuori, dovresti prendere in considerazione il refactoring o riscrivere l'area problematica, ma se non è troppo male (solo perché il codice spende il 90% delle volte in due o tre metodi non significa nulla se funziona in modo adeguato nel complesso) quindi continua a svilupparsi. Qualcosa che ho visto più di una volta sono sviluppatori che passano giornate ottimizzando la parte più complessa del sistema, solo per scoprire durante i test di integrazione che alcune parti non correlate del loro codice sono orribilmente lente.

Quando dovrei iniziare a pensarci? Quanto impegno dovrei mettere? Dipende dalla scala Cockburn del progetto. (In altre parole, qual è il rischio di non avere buone prestazioni?)

Apprendi in anticipo i principi fondamentali (consulta la risposta di Robert Harvey). Per applicare il pensiero orientato alla prestazione durante le varie fasi di sviluppo del software, lo sviluppatore deve conoscerlo interiormente, in modo tale che il processo di pensiero non sia ostacolato da tali considerazioni aggiuntive. (In altre parole, inizia a pensare alle prestazioni prima che il progetto sia concepito.)

Durante la fase iniziale di sviluppo, fai un uso liberale degli strumenti di profilazione delle prestazioni e tieni traccia della cronologia delle statistiche. Prestare particolare attenzione nell'organizzazione di tali informazioni per renderle utili per il successivo processo decisionale.

Quindi, a seconda della natura del progetto e della scala Cockburn:

• Prototipazione rapida, o "codice sbalorditivo come se non ci fosse un domani" o sviluppo interno con un basso impatto sul business: mantieni le statistiche. Non pensare ancora alle prestazioni. Implementa la funzione nel modo più semplice. Segui il primo algoritmo che ti viene in mente.

  • Nella seconda metà del progetto, ci saranno test delle prestazioni ad hoc per identificare "hotspot" basati su casi d'uso reali. Se c'è qualche problema di prestazioni che rende il software inutilizzabile, dovrebbe essere facilmente identificabile.
  • Per lo sviluppo interno con un basso impatto aziendale, è sufficiente implementare il codice e correggere i problemi di prestazioni più tardi.

• Applicazioni desktop che richiedono un approccio coerente e completo alle prestazioni. Non deve essere altamente ottimizzato; tuttavia, ci dovrebbe essere il minor numero possibile di "blocchi" (non reattività).

  • Le applicazioni desktop di solito hanno percorsi di esecuzione molto complessi che complicano il pensiero orientato alla prestazione. Un design a strati consentirà la separazione dei problemi di prestazioni del database / rete dai problemi di prestazioni della GUI, che verranno gestiti da diversi esperti nel proprio team.
  • Una cronologia delle tracce di Log consentirà l'identificazione degli hotspot.

• Elaborazione ad alte prestazioni, che richiede il massimo dalle prestazioni dell'hardware.

  • Nomini qualcuno nel tuo team per essere responsabile dell'analisi e della segnalazione delle statistiche sul rendimento.
  • Crea teorie sulle caratteristiche delle prestazioni, verifica con gli esperimenti e confronta le tue previsioni con modelli Comp Sci semplificati.
  *

All'inizio. Identificare le caratteristiche di prestazione richieste. Se non è possibile identificare l'obiettivo, è necessario fare un passo indietro per comprendere meglio i requisiti o differire finché non si conoscono i requisiti dei componenti con il rischio che si rischia di riscrivere. Quindi, prova. Non ottimizzare, testare. Se il codice non supera il test delle prestazioni, ottimizzare. Con un framework di test in atto, l'utilizzo di strumenti di monitoraggio delle prestazioni esistenti dovrebbe rendere l'attività ragionevolmente facile.

Mantenere i test delle prestazioni in atto per tutta la durata del progetto come test di regressione. Il codice di manutenzione è noto per innescare problemi di prestazioni perché le "correzioni" hanno spesso un focus molto ristretto.

Mi baso sempre su una formula semplice:

1. Falla funzionare
2. Rendi corretto
3. Rendi veloce

... in questo ordine.

Secondo c2 , questa formulazione è attribuita a Kent Beck .