Perché dovrei preoccuparmi delle prestazioni micro e dell'efficienza?

In pratica, le prestazioni raramente sono un problema che deve essere gestito con quel livello di dettaglio. Vale la pena tenere d'occhio la situazione se si sa che si stanno memorizzando e manipolando enormi quantità di dati, ma in caso contrario, hai ragione, e meglio, mantenendo le cose semplici.

Una delle trappole più facili da usare, specialmente in C e C ++ in cui si ha un controllo così preciso, sta ottimizzando troppo presto e a un livello troppo fine. In generale, la regola è: A) non ottimizzare finché non scopri di avere un problema, e B) non ottimizzare nulla che non hai dimostrato di essere un'area problematica utilizzando un profiler.

Un corollario a B) è: i programmatori sono notoriamente cattivi nel predire dove sono i loro colli di bottiglia nelle prestazioni, anche se, a uno, pensano di essere bravi a farlo. Utilizza un profiler e ottimizza le parti che sono lente o modifica gli algoritmi se una sezione di codice viene chiamata troppe volte, in modo che causi un problema.

Penso che tutto nella tua lista sia la micro-ottimizzazione, che in generale non dovrebbe essere guardata, ad eccezione di

using an O(n*n) vs O(NlogN) algorithm on a 100 item list

che penso dovrebbe essere visto. Certo, quella lista è di 100 articoli al momento, e tutto è veloce per piccoli n , ma sarei pronto a scommettere presto che lo stesso codice verrà riutilizzato per diversi milioni di elenchi di linee e il codice dovrà comunque funzionare in modo ragionevole.

La scelta dell'algoritmo corretto è mai una micro-ottimizzazione. Non si sa mai quali tipi di dati verranno utilizzati per lo stesso codice per due mesi o due anni dopo. A differenza delle "micro-ottimizzazioni" che sono facili da applicare con la guida di un profiler, le modifiche dell'algoritmo spesso richiedono una riprogettazione significativa per utilizzare in modo efficace i nuovi algoritmi. (Ad esempio, alcuni algoritmi richiedono che i dati di input siano già ordinati, il che potrebbe costringerti a modificare parti significative delle tue applicazioni per garantire che i dati rimangano ordinati)

Un po 'di tempo fa, nel mio primo lavoro, ho scritto il codice per i sistemi embedded. Questi sistemi utilizzavano 8086 microprocessori e avevano una memoria limitata. Abbiamo usato il compilatore C di Intel. Un sistema che ho costruito era necessario per accedere a una matrice di strutture 3-d. L'ho costruito proprio come mi ha detto il libro: chiama malloc per le 3 dimensioni, quindi alloca le righe per la dimensione successiva, quindi calloc per i nodi finali.

È stato piuttosto complicato (per me all'epoca), ho dovuto eseguire il fitting della curva, il controllo del processo ANOVA e l'analisi del chi quadrato. Non c'erano biblioteche che facessero questo per noi; abbiamo dovuto scrivere tutto e montare tutto su 8086.

Il sistema funzionava come un cane. Dopo una rapida profilazione, ho scoperto che uno dei maggiori problemi era l'allocatore. Per risolvere il problema ho abbandonato tutte le chiamate a malloc e ho fatto la mia gestione della memoria di un grande blocco di memoria.

In un altro caso sullo stesso lavoro, il cliente si lamentava del tempo di risposta sul proprio sistema di controllo statistico dei processi. Il team prima di me aveva progettato un sistema "software PLC" in cui gli operatori potevano utilizzare una logica booleana per combinare segnali e interruttori di scatto. L'hanno scritto in un linguaggio semplificato, quello che oggi chiameremmo "linguaggio specifico di dominio". come ricordo, sembrava ((A1 + B1) > 4) AND (C1 > C2) e così via.

Il progetto originale analizzava e interpretava quella stringa ogni volta che veniva valutata. Sul nostro misero processore, questo ha consumato un sacco di tempo, e ciò significava che il controllore del processo non poteva aggiornarsi tanto velocemente quanto il processo era in esecuzione.

Ne ho dato una nuova occhiata e ho deciso di tradurre quella logica in codice assembly, in fase di runtime. L'ho analizzato una volta e poi ogni volta che è stato eseguito, l'app ha chiamato in una funzione generata dinamicamente. Un po 'come fanno alcuni virus oggi, immagino (ma non lo so). Il risultato è stato un aumento di 100 volte delle prestazioni, che ha reso il cliente e il mio capo davvero molto felici.

Il nuovo codice non era quasi manutenibile, dato che avevo creato un compilatore personalizzato. Ma il vantaggio prestazionale ha superato di gran lunga lo svantaggio di manutenzione.

Più di recente stavo lavorando a un sistema che doveva analizzare un volo XML, in modo dinamico. I file più grandi richiederebbero molto più tempo. Questo era molto sensibile alle prestazioni; troppo lento di un parsing causerebbe l'UI diventare completamente inutilizzabile.

Questo genere di cose si manifestano continuamente.

Quindi .... a volte vuoi un codice manutenibile e facile da scrivere. A volte vuoi un codice che funzioni velocemente. Il compromesso è la decisione ingegneristica che devi prendere, su ogni progetto.

Se stai elaborando immagini di grandi dimensioni e iterando su ogni pixel, il perfezionamento delle prestazioni può essere fondamentale.

Lascia che ti spieghi un po 'del perché dietro la cultura.

Se sei più vicino a 40 che a 20, e hai programmato di vivere durante i tuoi anni da adulto, allora sei diventato maggiorenne quando C ++ era davvero l'unico gioco in città, le app desktop erano la norma, e l'hardware era ancora un software molto lento in termini di capacità di banda / prestazioni.

• Dovevamo fare stupidi trucchi di programmazione per poter leggere file grandi (> 2G) ...
• Ci siamo preoccupati delle dimensioni dell'eseguibile ...
• Ci siamo preoccupati di quanta memoria stavano consumando i nostri programmi ...
• Abbiamo regolarmente preso decisioni algoritmiche contro il tempo e lo spazio ...
• Anche nel back-end, avevamo per scrivere programmi CGI in C o C ++ per qualsiasi cosa per gestire un numero decente. di RPS ... Era diversi ordini di grandezza più veloce.
• Avevamo eseguito test sul merito delle prestazioni tra delphi / c ++ / vb!

Molto poche persone devono preoccuparsi di queste cose oggi.

Tuttavia, 10 anni fa dovevi ancora preoccuparti del fatto che il tuo software fosse scaricato su un modem a 56kb, e che venisse eseguito su un PC vecchio di 5 anni ... Ti ricordi di quanti PC erano schifosi nel 1996? Pensa in termini di 4 GB di disco rigido, un processore da 200 Mhz e 128 Mb di RAM ...

E i server di 10 anni fa? Il server di "prossima generazione" di Dell costa $ 2000 e viene fornito con processori pentium 2 (!) Da 1Ghz, 2Gb o Ram e un disco rigido da 20 GB.

Era semplicemente un ballgame diverso , e tutti quegli ingegneri "senior" con 10 anni di esperienza (i ragazzi probabilmente rispondono alle tue domande), tagliare i denti in quell'ambiente.

ci sono già 10 risposte qui e alcune sono davvero buone, ma perché questa è una mia personale petizione ...

ottimizzazione prematura che a) richiede più tempo per fare che una semplice soluzione b) introduce più codice dove la soluzione semplice sarebbe stata metà delle dimensioni e metà della complessità ec) rende le cose meno leggibili è ASSOLUTAMENTE dovrebbe essere evitato. Tuttavia, se uno sviluppatore ha una scelta tra l'uso di una std :: map o std :: vector e sceglie la raccolta sbagliata per pura ignoranza per prestazioni che sono altrettanto buone se non peggiore dell'ottimizzazione prematura. Cosa succederebbe se tu potessi cambiare leggermente il tuo codice oggi, mantenere la leggibilità, mantenere la stessa complessità, ma renderlo più efficiente, lo faresti? O lo chiameresti "ottimizzazione prematura"? Trovo che molte persone non possano nemmeno pensarci in un modo o nell'altro.

Una volta ero il ragazzo che consigliava la "micro-ottimizzazione" che richiedeva pochissimi cambiamenti e mi è stata data la stessa risposta che hai appena detto "non dovresti ottimizzare troppo presto. Facciamolo funzionare e noi" Lo cambierò più tardi se c'è un problema di prestazioni ". Ci sono volute diverse versioni prima di risolverlo. E sì, è stato un problema di prestazioni.

Anche se l'ottimizzazione iniziale potrebbe non essere buona, penso che sia molto utile se le persone scrivono codice comprendendo ciò che quel codice sta per fare e non ignorano semplicemente ogni domanda che risulta nella notazione O (x) come "ottimizzazione" ". C'è un sacco di codice che puoi scrivere ora e con un minimo di riflessione sulle prestazioni, evita l'80% dei problemi lungo la strada.

Considera anche che non si verificheranno molti problemi di prestazioni nel tuo ambiente e non subito. Alcune volte avrai un cliente che spinge il limite o un altro sviluppatore decide di costruire sopra il tuo framework e aumentare il numero di oggetti di 10 volte. Con un po 'di prestazioni, ora, si potrebbe evitare una riprogettazione molto costosa in seguito. E se il problema si verifica dopo che il software è stato ufficialmente rilasciato, anche una semplice correzione diventa 20 volte più costosa da applicare.

Quindi, in conclusione, tenere a mente le prestazioni in ogni momento aiuta a sviluppare buone abitudini. Che sono altrettanto importanti avere come scrivere pulito, il più semplice possibile e organizzato codice.

Sospetto che molto di quello che vedi sia un semplice errore di campionamento. Quando le persone hanno a che fare con situazioni dirette, scrivono il codice e questa è la fine delle cose. Fanno domande quando hanno a che fare con qualcosa di relativamente difficile, come la necessità di ottimizzare, specialmente in una situazione in cui non è necessariamente ovvio che sarebbe necessaria l'ottimizzazione.

Detto questo, c'è indubbiamente anche qualche ottimizzazione prematura. Correttamente o meno, C e C ++ hanno una reputazione per le prestazioni, che tende ad attirare le persone che si preoccupano delle prestazioni - comprese quelle che possono fare l'ottimizzazione tanto per il divertimento quanto perché è davvero necessaria.

Un paio delle altre risposte menzionano sistemi incorporati e mi piacerebbe approfondire questo aspetto.

Esistono molti dispositivi che contengono processori di fascia bassa, ad esempio: il controller della caldaia in casa o un semplice calcolatore tascabile o le dozzine di chip all'interno di un'auto moderna.

Per risparmiare, questi possono avere quantità di flash (per memorizzare codice) e RAM che sembrano minuscole per coloro che hanno solo scritto codice per PC o smartphone. Per risparmiare energia, potrebbero funzionare a frequenze di clock relativamente basse.

Per fare un esempio, la famiglia STM32 di microcontrollori va da 24 MHz, 16 KB di memoria flash e 4 KB di RAM , fino a 120 MHz, flash da 1 MB e RAM da 128 KB .

Quando si scrive codice per chip come questi, si risparmia un sacco di tempo se si mira a rendere il proprio codice il più efficiente possibile naturalmente. Ovviamente, l'ottimizzazione prematura rimane una cattiva idea; ma con la pratica, si impara come risolvere i problemi più rapidamente rapidamente e / o con risorse minime e codificare di conseguenza.

Essendo essenzialmente linguaggi di basso livello, quando ci si imbatte in un caso di prestazioni patologiche in cui un dettaglio che non importa il 99% delle volte causa il collo di bottiglia the , si ha effettivamente l'opportunità di lavorare direttamente sul problema (diversamente dalla maggior parte delle altre lingue); ma, naturalmente, spesso, come farlo nel modo più efficace non è immediatamente evidente. Di qui la metà delle domande di micro-ottimizzazione strane / interessanti qui poste.

L'altra metà viene da coloro che sono curiosi di sapere quanto possono avvicinarsi al metallo. Questi sono essenzialmente linguaggi di basso livello, dopotutto ...

Le prestazioni sono sempre un argomento caldo quando hai a che fare con C e C ++. Riguardo a quanto si dovrebbe andare lontano, si può sempre impazzire al punto di ASM in linea, o usando l'aritmetica del puntatore per un'iterazione più veloce. Tuttavia, arriva un punto in cui si spende così tanto tempo per ottimizzare il lavoro sullo sviluppo del programma generale.

Quando si affrontano questi problemi, ci sono prestazioni del programmatore e prestazioni del codice. Su quali di questi concentrarsi verranno sempre poste domande interessanti. Alla fine la domanda più importante è quanto sia visibile all'utente. L'utente lavorerà con i dati che creano array con centinaia o migliaia di elementi? In questo caso la codifica per fare in modo che le cose vadano rapidamente potrebbe far lamentare all'utente che le operazioni standard del programma sono lente.

Poi c'è l'utente che lavorerà con piccole quantità di dati. Alcuni file qua e là, dove operazioni come l'ordinamento e le operazioni sui file non saranno così evidenti per l'utente se utilizzi funzioni di livello superiore che semplificano la manutenzione al costo di alcune prestazioni.

Questo è solo un piccolo esempio dei problemi che incontrerai. Altre questioni includono l'hardware dell'utente di destinazione. Dovrai preoccuparti molto delle prestazioni se gestisci sistemi embedded, quindi se i tuoi utenti hanno, ad esempio, macchine dual core con ram di ram.

Perché i programmatori si preoccupano così tanto? Ci sono idee sciocche che popolano le loro teste, come risolvere problemi di prestazioni prima che sappiano di averli, e non capire quando sono indovinare .

È difficile perché, secondo la mia esperienza, ci sono alcuni problemi di prestazioni che un dovrebbe pensare in anticipo. Ci vuole esperienza per sapere cosa sono.

Detto questo, il metodo che uso è simile al tuo, ma non è lo stesso:

1. Inizia con il progetto più semplice possibile. In particolare, la struttura dei dati dovrebbe essere il più possibile normalizzata e minimizzata. Nella misura in cui ha una ridondanza inevitabile, si dovrebbe essere timidi delle notifiche come un modo per mantenerlo coerente. È meglio tollerare l'incoerenza temporanea e ripararla con un processo periodico.

2. Quando il programma è in fase di sviluppo, esegui periodicamente il tuning delle prestazioni, perché i problemi di prestazioni hanno un modo per insinuarsi lentamente. Il metodo che utilizzo è pausa casuale , perché penso sia il migliore.

Ecco un esempio dettagliato di cosa intendo.

Per essere onesti, dipende da quale è il tuo obiettivo e se stai programmando professionalmente o come hobby.

Al giorno d'oggi, i computer moderni sono macchine davvero potenti. Indipendentemente dalle operazioni di base che decidi di fare, che tu stia tentando di ottimizzare o meno il micro, possono rendere il loro lavoro straordinariamente veloce. Ma ovviamente, se stai facendo qualcos'altro (ad esempio, il supercalcolo per campi come la fisica o la chimica), potresti voler ottimizzare quanto vuoi.

I primi programmatori del MIT non erano nati per fare cose fantastiche; Hanno iniziato a semplificare e alimentare gli algoritmi esistenti. Il loro orgoglio era quello di rendere 2 + 2 dare quattro in due secondi in meno dell'algoritmo esistente (questo è solo un esempio, si ottiene l'idea). Hanno costantemente cercato di utilizzare meno schede perforate nelle loro macchine TI-83 per prestazioni.

Inoltre, se stai programmando per sistemi embedded, devi certamente tenere d'occhio le prestazioni micro. Non vuoi avere un orologio digitale lento che tocchi un secondo 5 nanosecondi prima di un altro orologio digitale.

Infine, se sei un programmatore hobbista, non c'è sicuramente alcun danno nell'ottimizzare i più piccoli dettagli anche se il tuo programma è veloce. Non è necessario, ma certamente qualcosa su cui puoi lavorare e cogliere l'occasione per saperne di più. Se lavori professionalmente in un software, non puoi prendere quel lusso a meno che non sia estremamente necessario.

using an O(N2) vs O(NlogN) algorithm on a 100 item list.

Recentemente mi trovavo in una situazione simile. Ho avuto una serie di elementi. Nel caso previsto, c'erano due (!) Articoli nella lista, e anche nel peggiore dei casi non mi aspetto più di quattro o forse otto.

Avevo bisogno di ordinare quella lista. Risulta, sostituendo std::sort con una rete di ordinamento (essenzialmente un sacco di% annidatoif s) rasata una grande percentuale del tempo di esecuzione (non ricordo il numero ma era qualcosa come 10-20%). Questo è un enorme vantaggio di una micro-ottimizzazione, e il codice è assolutamente critico per le prestazioni.

Naturalmente, ho fatto solo questa dopo profilazione. Ma il punto è che se uso un linguaggio scomodo e complicato come C ++ (per non parlare delle sue regole esasperatamente complesse per la risoluzione del sovraccarico), allora voglio ottenere tutti i benefici.

Uso di energia cumulativo

C'è una risposta che penso sempre manchi di queste discussioni e che mi disturba un po '- uso di energia cumulativo .

Certo, forse non importa molto se scrivi il tuo programma in un linguaggio interpretato ad alto livello e fallo girare in un browser con un paio di livelli di riferimento indiretto, o se il tuo ciclo richiede 0,01 secondi invece di 0,001 secondi. Nessuno se ne accorgerà, cioè nessun utente individuale noterà.

Ma quando decine di migliaia, o anche milioni di utenti in alcuni casi usano il tuo codice, tutta questa inefficienza aggiuntiva si aggiunge. Se il tuo strumento impedisce ad una CPU di entrare nello stato di sospensione per soli dieci secondi al giorno, e un milione di utenti lo usano, il tuo algoritmo inefficiente ha utilizzato solo un extra di 140 kWh ^[1] al giorno.

Raramente vedo questo discusso, e penso che sia triste. Sospetto strongmente che le cifre siano molto peggiori per i framework più diffusi, come Firefox e le fantastiche applicazioni web interattive, e sarebbe interessante da ricercare.

^{[1] L'ho appena fatto, 10 milioni di secondi per 50 Watt. La cifra esatta dipende da molte cose.}

A volte hai solo algoritmi che non possono essere migliori del tempo lineare per il quale esiste ancora una strong domanda di prestazioni.

Un esempio è l'elaborazione video in cui non è possibile rendere un'immagine / frame più luminosa come un esempio di base senza eseguire il ciclo di ogni pixel (beh, suppongo che tu possa con una sorta di struttura gerarchica che indica le proprietà ereditate dai bambini che alla fine scendono nelle tessere dell'immagine per i nodi foglia, ma in questo modo si rinvierebbe un costo più elevato del looping di ogni pixel al renderer e il codice sarebbe probabilmente più difficile da mantenere rispetto al filtro immagine più ottimizzato per micro).

Ci sono molti casi come quello nel mio campo. Tendo a fare loop più lineari e complessi che devono toccare tutto o leggere qualsiasi cosa rispetto a quelli che beneficiano di qualsiasi tipo di sofisticata struttura o algoritmo di dati. Non c'è lavoro che può essere saltato quando tutto deve essere toccato. Quindi a quel punto, se stai inevitabilmente affrontando una complessità lineare, devi rendere il lavoro fatto per iterazione più economica ed economica.

Quindi nel mio caso le ottimizzazioni più importanti e comuni sono spesso rappresentazioni di dati e layout di memoria, multithreading e SIMD (in genere in questo ordine con la rappresentazione dei dati è il più importante, in quanto influisce sulla possibilità di eseguire questi ultimi due). Non sto incontrando così tanti problemi che vengono risolti da alberi, tabelle di hash, algoritmi di ordinamento e cose del genere. Il mio codice giornaliero è più in vena di, "per ogni cosa, fai qualcosa."

Ovviamente è un altro caso di cui parlare quando sono necessarie le ottimizzazioni (e soprattutto, quando non lo sono), micro o algoritmico. Ma nel mio caso particolare, se un percorso di esecuzione critico ha bisogno di ottimizzazione, i guadagni di velocità 10x + sono spesso raggiunti da ottimizzazioni a livello micro come il multithreading, il SIMD e la riorganizzazione dei layout di memoria e dei pattern di accesso per una miglior localizzazione di riferimento. Non è così spesso che, per esempio, sostituisco un bubble sort con un introsort o un radix sort o un rilevamento di collisioni con complessità quadratica con un BVH, così come trovare hotspot che, ad esempio, traggano beneficio dalla divisione del campo caldo / freddo.

Ora nel mio caso il mio campo è così cruciale per le prestazioni (raytracing, motori fisici, ecc.) che un raytracer lento ma perfettamente corretto che impiega 10 ore per il rendering di un'immagine è spesso considerato inutile o più veloce di completamente interattivo, ma restituisce le immagini più brutte con i raggi che fuoriescono ovunque a causa della mancanza di raggi stagne / tri intersezione. La velocità è probabilmente la metrica di qualità primaria di tale software, probabilmente anche più della correttezza ad un certo punto (poiché la "correttezza" è un'idea sfocata con raytracing poiché tutto si sta approssimando, purché non si verifichi un arresto anomalo o qualcosa del genere). E quando questo è il caso, se non penso all'efficienza in anticipo, trovo che devo effettivamente cambiare il codice al livello di progettazione più costoso per gestire progetti più efficienti. Quindi, se non penso sufficientemente all'efficienza in anticipo quando progettiamo qualcosa come un raytracer o un motore fisico, è probabile che dovrei dover riscrivere l'intera dannata cosa prima che possa essere considerata abbastanza utile nella produzione e dagli utenti effettivi, non da gli ingegneri.

Il gioco è un altro campo simile al mio. Non importa quanto sia corretta la tua logica di gioco o quanto sia gestibile e brillantemente progettata la tua base di codice è se il tuo gioco funziona a 1 fotogramma al secondo come una presentazione. In alcuni campi la mancanza di velocità potrebbe effettivamente rendere l'applicazione inutile ai suoi utenti. A differenza dei giochi, non esiste una metrica "abbastanza buona" in aree come il raytracing. Gli utenti vogliono sempre più velocità e la competizione industriale è prevalentemente alla ricerca di soluzioni più veloci. Non sarà mai abbastanza buono fino a quando non sarà in tempo reale, a quel punto i giochi useranno i tracciatori di percorso. E quindi probabilmente non sarà ancora abbastanza buono per VFX, da allora gli artisti potrebbero voler caricare miliardi di poligoni e avere simulazioni di particelle con auto-collisione tra miliardi di particelle a oltre 30 FPS.

Ora, se è di conforto, nonostante ciò scrivo ancora circa il 90% del codice in un linguaggio di scripting (Lua) senza preoccupazioni per le prestazioni. Ma ho una quantità insolitamente grande di codice che ha effettivamente bisogno di passare da milioni a miliardi di cose, e quando passi da milioni a miliardi di cose, inizi a notare una differenza epica tra il codice ingenuo single-threaded che richiama un errore di cache con ogni iterazione, per esempio, codice in esecuzione in parallelo che accede a blocchi contigui dove nessun dato irrilevante viene caricato in una linea della cache.

Come hai detto, i problemi relativi alle prestazioni micro non hanno alcun valore prima di tenere conto di alcuni problemi realmente causati da questi problemi

È davvero impossibile rispondere a questa domanda in generale. La maggior parte dei software che vengono creati oggi sono siti Web interni e applicazioni LOB, e per quel tipo di programmazione il tuo ragionamento è abbastanza corretto. Dall'altra parte, se si scrive qualcosa come un driver di periferica o un motore di gioco, nessuna ottimizzazione è "prematura"; è probabile che il tuo software funzioni su sistemi molto diversi con diversi vincoli hardware. In tal caso, dovresti progettare le prestazioni e assicurarti di non scegliere un algoritmo non ottimale.

Penso che il problema del programmatore, che si preoccupa tanto delle prestazioni è che, a volte nella sua vita, aveva bisogno di scrivere codice micro-performante, forse con molta urgenza, e ha imparato, imparato, imparato e alla fine sapeva un sacco di cose e trucchi.

E ora è difficile da dimenticare, e senza una misura preventiva, che mostra, che non ha bisogno di preoccuparsi, è sul lato sicuro, usando un codice veloce.

È sempre bello mostrare la tua profonda conoscenza, le tue abilità e alcuni trucchi e riutilizzare qualcosa che hai imparato. Ti fa sentire prezioso e il tempo spende per l'apprendimento, vale la pena.

A volte nella mia vita, ho imparato che l'incremento del prefisso è più veloce ...

for (int i = 0; i < MAX; ++i)

... di incremento postfix:

for (int i = 0; i < MAX; i++)

Ora, se MAX è basso, non importa, e se c'è un vero lavoro nel ciclo, non avrà importanza. Ma non c'è un motivo per usare la versione postfix, anche se il compilatore di oggi ottimizza il codice da solo.

Forse i cercatori di prestazioni hanno bisogno di un obiettivo aggiuntivo, oltre a scrivere "codice di lavoro", come "codice funzionante e leggibile" per avere una linea guida nel grande mare delle opzioni.

have I just been lucky enough to not to have to worry too much about it, or am I a bad programmer?

Ti piacciono le tue esigenze? Se le prestazioni non sono un requisito, non preoccuparti. Trascorrere un periodo significativo è un disservizio per il datore di lavoro.

In un certo senso la prestazione è sempre un requisito. Se riesci a colpirlo senza pensarci, sei giustificato a non pensarci.

Personalmente, sono spesso guidato dalle prestazioni quando i miei test impiegano molto tempo per passare. Sono troppo impaziente di aspettare 5 minuti mentre passa una serie di test. Ma di solito si risolve giocherellando con i test.

My question is why is it that a large number of programmers care so much? Is it really an issue for most developers,

Ci sono un gran numero di programmatori che sono giustificati in quanto a loro importa. Ci sono grandi numeri che non lo sono. Parliamo di quelli che non lo sono.

Una delle prime cose che i programmatori imparano a scuola, dopo come far funzionare effettivamente le cose, è la notazione O grande. Molti di loro imparano la lezione correttamente e quindi si focalizzano correttamente su cose drammaticamente influenzate da n. Altri non prendono la matematica e tolgono solo la lezione che una volta che funziona ha bisogno di essere veloce. Peggio ancora, alcuni di questi studenti non imparano nient'altro su cosa è importante fare con il tuo codice, oltre a farlo funzionare e farlo funzionare velocemente. Le lezioni perse: renderlo leggibile, disegnarlo bene, non giocarci senza motivo.

Knuth aveva ragione: l'ottimizzazione prematura è la radice di tutto il male. Ma una volta che funziona, qual è il prossimo passo? Veloce giusto? NO! Il prossimo passo è leggibile. Leggibile è il primo, il prossimo, il secondo e l'ultimo passo. Molte delle persone che trovo di fare ottimizzazioni delle prestazioni non necessarie stanno lanciando la leggibilità sotto il bus.

Alcuni hanno persino un brivido perverso di quanto il loro codice sia illeggibile. Hanno dovuto soffrire guardando il codice difficile da capire creato da altri, quindi ora è il loro turno al momento del recupero.

Lo so perché lo facevo. Una volta ho rifatto un 5 righe perfettamente leggibili, se la struttura è stata decifrata da un'espressione booleana indecifrabile, e l'ho spedita con orgoglio al mio professore, aspettandomi di impressionare, poiché avrei potuto creare qualcosa di così compatto e intimidatorio. Non ho ricevuto le lodi che speravo.

Se il codice rimane leggibile, renderlo più veloce in seguito è facile. Ecco perché Knuth sottolinea "prematura" non "non necessaria". Perché sicuro, più veloce è meglio. Ma meglio è solo meglio a seconda di ciò che sacrifichi per questo. Quindi aspetta di sapere quali prestazioni hai veramente bisogno prima di fare sacrifici per questo. Sacrifica la leggibilità a malincuore perché una volta che se ne è andato, è difficile tornare indietro.

Oltre la leggibilità è l'intero mondo del software design. Di cosa tratta questo sito. Alcuni non hanno idea di cosa fare per quanto riguarda il design. Quindi, dato che non riescono a impressionare con il design, creano un pasticcio indecifrabile, quindi le persone non possono dire di non avere idea. Dal momento che nessuno aggiusta mai il loro codice, deve essere un buon codice, giusto?

Per alcuni, le prestazioni sono il pretesto per fare quello che vogliono. I programmatori hanno molta potenza e autonomia. La fiducia è stata messa in loro. Non abusare della fiducia.