L'ottimizzazione prematura si sviluppa su macchine lente?

Question

Dovremmo sviluppare il boxen lento perché ci obbliga a ottimizzare in anticipo.

Randall Hyde sottolinea nel The Fallacy of Premature Optimization, ci sono un sacco di idee sbagliate intorno alla citazione Hoare:

Dobbiamo dimenticare le piccole efficienze, dicono circa il 97% del tempo: l'ottimizzazione prematura è la radice di tutto il male

In particolare, anche se le macchine di questi tempi urlano rispetto a quelle dei giorni di Hoare, ciò non significa "l'ottimizzazione dovrebbe essere evitata". Quindi il mio stimato collega ha ragione quando suggerisce che dovremmo sviluppare delle scatole di un tempo modesto? L'idea è che i colli di bottiglia delle prestazioni sono più irritanti su una scatola lenta e quindi è probabile che ricevano attenzione.

Answer 1

I computer lenti non ti aiuteranno a trovare i tuoi problemi di prestazioni.

Se i dati di test sono solo poche centinaia di righe in una tabella, il db memorizzerà tutto nella cache e non troverà mai query scritte male o design di tabelle/indici errati. Se l'applicazione server non è un server multithreading, non la troverai fino a quando non la sottoponi a test con 500 utenti. O se i colli di bottiglia app su larghezza di banda.

L'ottimizzazione è "Una buona cosa", ma come dico ai nuovi sviluppatori che hanno ogni sorta di idee su come farlo meglio "Non mi interessa quanto velocemente mi dai la risposta sbagliata". Prendilo per primo, quindi rendilo più veloce quando trovi un collo di bottiglia. Un programmatore esperto lo progetterà e lo costruirà abbastanza bene per iniziare.

Se le prestazioni sono davvero critiche (transazioni in tempo reale? Millisecondo?), Allora è necessario progettare e implementare una serie di benchmark e strumenti per dimostrare scientificamente a se stessi che i cambiamenti stanno rendendo più veloce. Ci sono troppe variabili là fuori che influenzano le prestazioni.

In più c'è la classica scusa del programmatore che faranno uscire - 'ma è lento perché abbiamo deliberatamente selezionato computer lenti, funzionerà molto più velocemente quando lo implementeremo.'

Se il collega pensa che la sua importante dargli un computer lento e lo mise a capo di 'prestazioni' :-)

Answer 2

Questo dovrebbe essere wiki della comunità poiché è piuttosto soggettivo e non c'è una risposta "giusta".

Detto questo, dovresti sviluppare la macchina più veloce a tua disposizione. Sì, qualsiasi cosa più lenta introdurrà irritazione e ti incoraggerà a correggere i rallentamenti, ma solo a un prezzo molto alto:

La tua produttività come programmatore è direttamente correlata al numero di cose che puoi tenere nella tua testa, e tutto ciò che rallenta il tuo processo o ti impedisce di allungare la quantità di tempo in cui devi tenere quelle idee nella memoria a breve termine, rendendoti più probabile dimenticarle e doverle riapprendere.

In attesa di un programma da compilare, è possibile che la pila di bug, potenziali problemi e correzioni scompaiano dalla propria mente man mano che ci si distrae. In attesa di una finestra di dialogo da caricare, o una query per finire ti interrompe in modo simile.

Anche se ignori questo effetto, hai ancora la verità dell'affermazione successiva: l'ottimizzazione iniziale ti lascerà inseguire in tondo, rompendo il codice che già funziona e indovinando (con scarsa precisione) su dove le cose potrebbero impantanarsi. Progettate il vostro codice in modo appropriato e dimenticatevi dell'ottimizzazione fino a quando non avrete la possibilità di accontentarvi un po ', a quel punto qualsiasi ottimizzazione necessaria sarà ovvia.

Answer 3

dipende dal vostro tempo di consegna. Se hai un ciclo di consegna di 12 mesi, dovresti sviluppare una scatola con una velocità decente poiché i 12 mesi di tempo dei tuoi clienti avranno migliori "media" di scatole rispetto alla "media" attuale.

Mentre il tuo ciclo di sviluppo si avvicina a "oggi", le tue macchine di sviluppo dovrebbero avvicinarsi all'attuale velocità "media" delle scatole dei tuoi clienti.

Answer 4

Immagino dipenda da ciò che state facendo e dal pubblico previsto.

Se si sta scrivendo software per hardware fisso (ad esempio giochi per console), quindi utilizzare l'apparecchiatura (almeno l'apparecchiatura di prova) simile o uguale a quella su cui verrà distribuito.

Se stai sviluppando app desktop o qualcosa del genere, allora sviluppa su qualsiasi macchina tu voglia e poi esegui l'ottimizzazione per eseguire l'hardware min-spec desiderato. Allo stesso modo, se stai sviluppando software in-house, è probabile che ci sia una minima specifica per le macchine che l'azienda vuole acquistare. In tal caso, sviluppare su una macchina veloce (per ridurre i tempi di sviluppo e quindi i costi) e testare contro tale min-spec.

In conclusione, sviluppate la macchina più veloce su cui potete mettere le mani e provate l'hardware minimo o esatto che sosterrete.

Answer 5

In genere sviluppo sulla macchina più veloce a cui riesco a mettere le mani.

La maggior parte delle volte eseguo una compilazione di debug, che è già abbastanza lenta.

Answer 6

per amore di Codd, utilizzare strumenti di profiling, non macchine di sviluppo lento!

Answer 7

L'ottimizzazione dovrebbe essere evitata, non ci ha offerto Vista? : p

Ma in tutta serietà, è sempre una questione di compromessi. Domande importanti da porsi

Quale piattaforma useranno i vostri utenti finali? Posso rilasciare cicli? Cosa succederà se lo faccio?

Concordo sul fatto che lo sviluppo iniziale debba essere eseguito sulla macchina più veloce o più efficiente (non necessariamente la stessa) disponibile per voi. Ma per eseguire test, eseguirlo sulla piattaforma di destinazione e testare spesso e in anticipo.

Answer 8

Se si sta programmando su hardware vicino agli ambienti di test e di produzione finali, si tende a scoprire che ci sono meno brutte sorprese quando arriva il momento di rilasciare il codice.

Ho visto che un numero sufficiente di programmatori viene sballottato da problemi gravi, ma inaspettati, causati dal fatto che le loro macchine sono molto più veloci della maggior parte dei loro utenti. Ma ho anche visto lo stesso problema con i dati. Il codice viene testato su un piccolo set di dati e quindi "si sgretola" su uno grande.

Eventuali differenze negli ambienti di sviluppo e distribuzione possono essere all'origine di problemi imprevisti.

Tuttavia, poiché la programmazione è costosa e dispendiosa in termini di tempo, se l'utente finale utilizza apparecchiature obsolete, la soluzione migliore è affrontarla al momento del collaudo (e pianificare in alcuni test iniziali solo per verificare usabilità e tempistiche).

Perché paralizzare i programmatori solo perché sei preoccupato di perdere un potenziale problema? Questa non è una strategia di sviluppo equilibrata.

Paul.

Answer 9

Penso che sia un concetto sonoro (ma forse perché funziona per me).

Se la mia postazione di lavoro è troppo veloce, trovo che le idee non vengono pensate abbastanza semplicemente perché c'è poca penalità nel rigenerare l'immagine del software o scaricarla sul target. Direi che almeno la metà dei miei download non sono necessari perché mi sono appena ricordato di qualcosa che mi era sfuggito subito prima di eseguire il debug del codice.

La macchina di destinazione potrebbe contenere un processore limitato. Se - su un MCU incorporato - hai metà dei cicli FLASH, RAM e clock al secondo è probabile che gli sviluppatori saranno molto più attenti nella progettazione del loro codice. Una volta ho suggerito le variabili di byte per le lunghezze dei singoli record in un'area dati (non nella RAM ma in una eeprom seriale) e ho ricevuto la risposta "non è necessario essere avari". Alcuni mesi dopo hanno raggiunto il limite massimo della RAM (128 KiB). La mia riflessione è stata che per questa app non ci sarebbero mai stati record superiori a 256 byte semplicemente perché non c'era una RAM in cui copiarli.

Per le applicazioni server penso che sarebbe una buona idea avere un hardware (molto) dalle prestazioni inferiori su cui testare. Due o quattro core anziché sedici (o più). 1.6 GHz istdo 2.8. La lista continua. Di solito un server - a causa del fatto che tutti ne parlano - è un collo di bottiglia nell'architettura di sistema. E questo è molto prima di iniziare a sviluppare l'applicazione (server) per questo.