La micro-ottimizzazione è importante per la codifica?

170

Recentemente ho fatto una domanda su Stack Overflow per scoprire perché isset () era più veloce di strlen () in PHP . Ciò ha sollevato dubbi sull'importanza del codice leggibile e sul fatto che i miglioramenti delle prestazioni dei micro-secondi nel codice fossero degni di considerazione.

Mio padre è un programmatore in pensione, e gli ho mostrato le risposte. Era assolutamente certo che se un programmatore non considera le prestazioni nel proprio codice anche a livello micro, non sono dei buoni programmatori.

Non ne sono così sicuro - forse l'aumento della potenza di calcolo significa che non dobbiamo più considerare questo tipo di miglioramenti delle micro-prestazioni? Forse questo tipo di considerazione spetta alle persone che scrivono il codice della lingua attuale? (di PHP nel caso precedente).

I fattori ambientali potrebbero essere importanti: Internet consuma il 10% dell'energia mondiale. Mi chiedo quanto siano sprecati pochi micro secondi di codice quando vengono replicati migliaia di miliardi di volte su milioni di siti web?

Mi piacerebbe conoscere le risposte preferibilmente sulla base di fatti sulla programmazione.

La micro-ottimizzazione è importante per la codifica?

Il mio riassunto personale di 25 risposte, grazie a tutti.

A volte dobbiamo davvero preoccuparci delle micro-ottimizzazioni, ma solo in circostanze molto rare. Affidabilità e leggibilità sono molto più importanti nella maggior parte dei casi. Tuttavia, considerando la micro-ottimizzazione di tanto in tanto, non fa male. Una comprensione di base può aiutarci a non rendere evidenti le cattive scelte quando codifica come

if (expensiveFunction() || counter < X)

Dovrebbe essere

if (counter < X || expensiveFunction())

( Esempio da @ zidarsk8 ) Questa potrebbe essere una funzione economica e pertanto la modifica del codice sarebbe micro- ottimizzazione. Ma, con una comprensione di base, non dovresti farlo, perché in primo luogo dovresti scriverlo correttamente.

    
posta Boz 23.05.2017 - 14:40
fonte

30 risposte

84

Sono entrambi d'accordo e in disaccordo con tuo padre. Le prestazioni dovrebbero essere pensate in anticipo, ma la micro-ottimizzazione dovrebbe essere pensata solo in anticipo se in realtà conosci che un'alta percentuale di tempo sarà spesa in piccole sezioni di codice legate alla CPU.

Il problema con la micro-ottimizzazione è che di solito viene fatto senza avere alcun concetto di come i programmi effettivamente impieghino più tempo del necessario.

Questa conoscenza deriva dall'esperienza che esegue il tuning delle prestazioni, come in questo esempio , in cui un programma apparentemente semplice, senza evidenti inefficienze, viene eseguito attraverso una serie di passaggi di diagnosi e accelerazione, fino a quando non è 43 volte più veloce rispetto all'inizio.

Ciò che mostra è che non puoi davvero indovinare o intuire dove saranno i problemi. Se si esegue la diagnosi, che nel mio caso è pausa casuale , le linee di codice responsabili di una significativa frazione di tempo sono esposte preferenzialmente. Se guardi quelli, potresti trovare il codice sostitutivo e quindi ridurre il tempo complessivo approssimativamente di quella frazione.

Altre cose che non hai risolto richiedono ancora tanto tempo come prima, ma dato che il tempo complessivo è stato ridotto, quelle cose ora prendono una frazione più grande, quindi se lo fai di nuovo tutto, quella frazione può anche essere eliminato. Se continui a farlo su più iterazioni, è così che puoi ottenere massimi speedups, senza aver mai necessariamente effettuato alcuna micro-ottimizzazione .

Dopo questo tipo di esperienza, quando si affrontano nuovi problemi di programmazione, si arriva a riconoscere gli approcci progettuali che inizialmente portano a tali inefficienze. Secondo la mia esperienza, deriva dall'eccessiva progettazione della struttura dei dati, dalla struttura dei dati non normalizzata, dalla dipendenza massiccia dalle notifiche, da quel genere di cose.

    
risposta data 23.05.2017 - 14:40
fonte
116

La micro-ottimizzazione è importante solo se i numeri lo dicono.

I requisiti che si stanno sviluppando dovrebbero avere alcune specifiche dei dati sulle prestazioni, se le prestazioni sono un problema per il cliente o l'utente. Durante lo sviluppo del software, è necessario testare le prestazioni del sistema in base a questi requisiti. Se non si soddisfano i requisiti di prestazione, è necessario definire il proprio codice base e ottimizzare come necessario per raggiungere i requisiti di prestazione. Una volta che hai raggiunto le prestazioni minime richieste, non c'è bisogno di spremere ulteriori prestazioni dal sistema, specialmente se stai andando a compromettere la leggibilità e la manutenibilità del codice più (nella mia esperienza, il codice altamente ottimizzato è meno leggibile e manutenibile, ma non sempre). Se puoi ottenere ulteriori guadagni in termini di prestazioni senza degradare gli altri attributi di qualità del sistema, puoi considerarlo.

Ci sono casi, tuttavia, in cui le prestazioni sono della massima importanza. Sto principalmente pensando a sistemi in tempo reale e sistemi embedded. Nei sistemi in tempo reale, cambiare l'ordine delle operazioni può avere un enorme effetto sul rispetto delle scadenze rigide necessarie per il corretto funzionamento, forse anche influenzando i risultati dei calcoli. Nei sistemi integrati, in genere si dispone di memoria, alimentazione della CPU e alimentazione limitati (come nel caso della batteria), quindi è necessario ridurre la dimensione dei binari e ridurre il numero di calcoli per massimizzare la durata del sistema.

    
risposta data 08.08.2011 - 18:58
fonte
102

Ogni volta che qualcuno chiede di ottimizzazione , mi viene in mente la citazione di Michael A. Jackson

The First Rule of Program Optimisation: Don't do it.

The Second Rule of Program Optimisation (for experts only!): Don't do it yet.

Citazione da Wikipedia corretta per l'inglese britannico. * 8' )

La seconda regola implicita è profilo il tuo codice e impiegano solo tempo per ottimizzare le cose che faranno la differenza.

Durante la programmazione in assemblea, l'affermazione di tuo padre era corretta. Ma questo è molto più vicino al metallo di quanto la maggior parte delle persone programmino in questi giorni. Oggi anche provare per ottimizzare te stesso (senza profilazione) può far sì che il tuo codice esegua più lento di se avessi fatto qualcosa nel modo più comune, dal momento che il modo comune è più probabilmente ottimizzato dai moderni JIT compilatori.

Anche in C devi essere abbastanza bravo nell'ottimizzazione per sapere di più su come ottimizzare una sezione di codice rispetto al compilatore.

Se non hai familiarità con gran parte di ciò di cui parla Ulrich Drepper nel suo eccellente articolo Cosa dovrebbe fare ogni programmatore Conoscere la memoria , allora probabilmente stai perdendo il tentativo di ottimizzare te stesso. Tuttavia, contrariamente al titolo dei documenti (che in realtà è un omaggio allo stesso Quello che ogni scienziato informatico dovrebbe sapere sull'aritmetica a virgola mobile ) non avere questo livello di comprensione non ti impedisce necessariamente di essere un buon programmatore, ma solo un diverso tipo di programmatore.

isset() vs. strlen() in PHP

Non conosco PHP, quindi non è ovvio che cosa intenda fare isset() . Posso dedurlo dal contesto, ma questo significa che sarà ugualmente oscuro per i programmatori PHP principianti e potrebbe addirittura portare a un numero maggiore di programmatori più esperti. Questo è il tipo di uso idiomatico di un linguaggio che può rendere la manutenzione un incubo.

Non solo, ma non vi è alcuna garanzia che isset() sarà sempre più efficiente, solo perché ora è più efficiente. Un'ottimizzazione ora potrebbe non essere un'ottimizzazione l'anno prossimo o tra 10 anni. CPU, sistemi, compilatori migliorano e cambiano nel tempo. Se le prestazioni del strlen() di PHP sono un problema, PHP potrebbe essere modificato in futuro, quindi potrebbe essere necessario rimuovere tutte le ottimizzazioni di isset () per ottimizzare il codice ancora una volta.

Ogni ottimizzazione ha il potenziale per diventare un futuro anti-ottimizzazione , quindi dovrebbe essere considerato un possibile odore di codice, da mantenere al minimo.

Un esempio di esperienza personale

Come esempio di un anti-ottimizzazione , una volta ho dovuto disinfettare un'enorme base di codice piena di codice della forma if x==0 z=0 else z=x*y perché qualcuno aveva fatto l'ipotesi che un multiplo in virgola mobile fosse < em> sempre diventerà più costoso di un ramo. Nell'architettura di destinazione originale questa ottimizzazione ha reso il codice più veloce di un ordine di grandezza, ma i tempi cambiano.

Quando abbiamo provato ad usare questo codice su una CPU più moderna che era altamente pipeline, le prestazioni erano orribilmente cattive - ognuna di queste affermazioni causa un flush della pipeline. Semplificando tutte queste righe di codice a solo z=x*y il programma ha eseguito un ordine di grandezza più veloce sulla nuova architettura, ripristinando le prestazioni perse dall'anti-ottimizzazione .

I problemi che in genere dobbiamo ottimizzare per oggi sono molto diversi da quelli che dovevamo ottimizzare per 20 o anche 10 anni fa.

Quindi siamo preoccupati di fare il maggior numero di lavori per ciclo di clock, ora siamo più propensi a preoccuparci di svuotamenti di pipeline, errate previsioni delle branche e errori di cache a livello di CPU, ma i lock e la comunicazione tra processi stanno diventando molto più significativo quando passiamo alle architetture multiprocesso e multiprocessore. Il documento di Drepper può davvero aiutare a comprendere molti di questi problemi.

    
risposta data 04.04.2014 - 21:44
fonte
82
  1. Scrivi codice, che è pulito, conciso, semplice e autoesplicativo.
  2. Realizza test delle prestazioni per identificare i colli di bottiglia.
  3. Ottimizza le sezioni critiche.

Come regola generale: il 95% del tuo codice viene eseguito il 5% delle volte. Non ha senso ottimizzare prima di profilare / confrontare il tuo codice e vedere quali sono il 5% che vengono eseguiti il 95% delle volte.

Ogni idiota può fare micro-ottimizzazione e qualsiasi compilatore / runtime decente lo farà per te.
L'ottimizzazione del buon codice è banale. Scrivere codice ottimizzato e cercare di renderlo buono dopo è tedioso nel migliore dei casi e insostenibile nel peggiore dei casi.

Se prendi seriamente cura delle prestazioni, non utilizzare PHP per codice critico delle prestazioni. Trova i colli di bottiglia e riscrivili con le estensioni C. Anche la micro-ottimizzazione del tuo codice PHP oltre il punto di offuscamento non ti darà quasi la stessa velocità.

Personalmente, mi è piaciuto molto il micro-ottimizzazione quando ho iniziato a programmare. Perché è ovvio. Perché ti ricompensa velocemente. Perché non devi prendere decisioni importanti. È il mezzo perfetto di procrastinazione. Ti permette di scappare dalle parti veramente importanti dello sviluppo del software: la progettazione di sistemi scalabili, flessibili, estensibili e robusti.

    
risposta data 09.08.2011 - 16:33
fonte
25

Per prima cosa prendi il tuo caso: PHP

  • Non penso che PHP sia un tipo di linguaggio (sia per la sua natura che per il suo dominio principale di applicazione) che devi preoccuparti di queste "micro-ottimizzazioni". Il codice PHP è per lo più ottimizzato con il caching opcode.
  • I programmi scritti in PHP non sono legati alla CPU, sono principalmente I / O rilegati, quindi questi le ottimizzazioni non valgono comunque il tuo tempo.
  • Tutto ciò che DEVE ottimizzare dovrebbe probabilmente essere inserito in un'estensione C e quindi caricato dinamicamente nel runtime di PHP
  • Quindi, come puoi vedere, non otteniamo alcun incentivo ottimizzando il nostro codice in PHP - d'altra parte, se passi quel tempo a rendere il codice PHP più leggibile e mantenibile - questo ti pagherà più dividendi.

In generale,

Non spenderei "TOOOOO" per molto tempo per ottimizzare il mio codice in un linguaggio dinamico come Python oppure Ruby - perché, NON sono progettati per attività di crunch di numeri intensivi della CPU. Risolvono diversi tipi di problemi dove modellare una situazione del mondo reale in modo elaborato (che è facile da leggere e mantenere) - che è chiamato espressività - è più importante della velocità. Se la velocità fosse la preoccupazione principale, in primo luogo non sarebbero dinamici.

Per i programmi compilati (C ++, Java), l'ottimizzazione è più cruciale. Ma anche lì, per prima cosa devi guardare alla natura / dominio / scopo del programma che stai scrivendo. Dovresti inoltre valutare attentamente il tempo necessario per ottimizzare la micro-ottimizzazione rispetto ai guadagni derivanti dall'ottimizzazione. Se hai bisogno di ancora più ottimizzazione, allora puoi anche considerare di fare un passo indietro e codificare quei pezzi del tuo codice in assembler.

Quindi, per rispondere alla tua domanda iniziale: "La micro-ottimizzazione è importante per la codifica?" - la risposta è - DIPENDE -

  • Che tipo di cosa stai facendo: dominio delle applicazioni, complessità?
  • I miglioramenti della velocità in microsecondi sono DAVVERO importanti per il tuo programma?
  • Quale tipo di ottimizzazione sarà più redditizia? Potrebbe non essere sempre l'ottimizzazione del codice, ma qualcosa di esterno.
  • Quanta "bontà" (in termini di velocità) stai raccogliendo dal momento in cui investi la micro-ottimizzazione?
  • È possibile ottenere velocità migliori in altri modi, cambiando hardware, RAM e amp; processore, eseguendo codice parallelo o su un sistema distribuito?

Non solo la micro-ottimizzazione (ottimizzazione del codice per quella materia) richiede molto tempo, ma "distorce" la naturale leggibilità del tuo codice, rendendolo così pesante per la manutenzione. Considerala sempre come ultima risorsa: cerca sempre di ottimizzare l'intera applicazione adottando un hardware migliore e un'architettura migliore dell'ottimizzazione dei singoli file di codice.

    
risposta data 04.04.2014 - 21:49
fonte
23

Sarei d'accordo con tuo padre: "Se un programmatore non considera le prestazioni nel loro codice anche a livello micro, non sono dei buoni programmatori." La chiave è "considerare le prestazioni". Questo non equivale a "fare micro-ottimizzazioni ad ogni passo".

Sono d'accordo con la maggior parte degli altri commenti - quello che era solito rendere i programmi C più veloci oggi potrebbe non farlo - ma ci sono altre cose serie da considerare: dovrei usare C o C ++? Le classi con semplici operatori sovraccaricati possono uccidere le prestazioni se le si utilizza molto. È importante? Dipende dalla tua applicazione, ma se non lo consideri nemmeno, non sei un ottimo programmatore. Alcuni lo considerano per circa 2 millisecondi e lo eliminano, ma penso che troppi letteralmente non lo considerino nemmeno.

La realtà è che con l'ottimizzazione, il codice può diventare più difficile da leggere. Il codice impiegherà più tempo a scrivere. Il codice sarà da qualche parte tra un po 'più veloce e un ordine di grandezza più veloce (è raro). I tuoi clienti probabilmente non sapranno la differenza.

Un'altra realtà è che alle persone piace riutilizzare il codice e dove finisce potrebbe essere molto diverso da quando lo hai scritto. All'improvviso le persone potrebbero interessarsene.

Ad esempio, dì che hai scritto qualcosa come Angry Birds su un PC o per una console di gioco. Hai ignorato l'ottimizzazione del tuo sistema fisico e del tuo sistema grafico, perché i dual core a 2,5 GHz sono praticamente il minimo in questi giorni e il tuo gioco funziona abbastanza bene. Poi arrivano gli smartphone e tu vuoi portarlo. Oh dannazione, un ARM core a 600 MHz?

Pensa a un sito web - qualcosa che viene messo insieme in un fine settimana come Hot or Not . Puoi usare qualunque database sia a portata di mano, scrivere tutto con un rapido sviluppo in mente, lanciare via email ai tuoi amici un URL. Tre mesi dopo il server sta morendo per sovraccarico e non c'è nulla che tu possa fare per scalare. Succede tutto il tempo. I più grandi siti web hanno bollette energetiche misurate in centinaia di kilowatt o persino megawatt. Pensaci, ci sono megawatt da salvare attraverso l'ottimizzazione del codice.

Come ha detto tuo padre, devi almeno considerarlo . La maggior parte della gente non sa nemmeno quante prestazioni ci sono sul tavolo e la sorvola con una rapida battuta su "ottimizzazione prematura" e "non farlo". Questi non sono dei buoni programmatori.

Questa non è un'opinione popolare su questi siti. Addio punti reputazione ...

    
risposta data 04.04.2014 - 21:53
fonte
16

Sembra che ci siano molte risposte che dicono che l'ottimizzazione micro è

all about tradeoffs - performance, time, cost, effort, readability/maintainability, and so on.

Ma bene, so che ci sono alcune ottimizzazioni in cui non c'è alcun impatto sulla leggibilità, e mi piace solo farlo per divertimento. Ho visto alcuni dei miei incarichi scolastici (che erano tutti basati sulla velocità), che è sempre consigliabile prendere in considerazione la micro ottimizzazione quando si scrivono affermazioni condizionali come:

if (counter < X && shouldDoThis()) // shouldDoThis() is an expensive function

è sempre più carino di

if (shouldDoThis() && counter < X ) 

Ci sono molti modi per "accelerare" il tuo codice in questo modo e la differenza è generalmente trascurabile (non sempre però), ma mi sento meglio se scrivo così.

Non so se qualcuno la considera davvero un'ottimizzazione, ma penso che un programmatore dovrebbe conoscere e considerare queste cose quando scrive il loro codice.

    
risposta data 11.08.2012 - 05:15
fonte
11

All'inizio della mia carriera, affermazioni generiche come "non micro-ottimizzazione" hanno causato molta confusione. Tutto è circostanziale; quindi, la ragione per cui le persone dicono "best practice" piuttosto che "fai questo".

"Best practice" è la scelta migliore considerando tutte le circostanze. Ad esempio, LINQ e Entity Framework deve essere utilizzato al posto di inline SQL. Nella mia azienda siamo su SQL Server 2000 . SQL Server 2000 non supporta Entity Framework. Le best practice richiedono:

  • Vendendo il mio capo sull'idea di acquistare una nuova versione di SQL Server che significa diverse migliaia di dollari.
  • Vendere gli sviluppatori sull'idea di imparare nuove tecnologie.

So per esperienza che questo non accadrà. Quindi, potrei smettere, stressare senza fine o non seguire le migliori pratiche.

Ci sono considerazioni politiche, tecniche e monetarie dietro le decisioni che influenzano il risultato complessivo. Ricorda questo fatto quando prendi una decisione e scegli le tue battaglie con saggezza.

" Per ogni cosa c'è una stagione, un momento per ogni attività sotto il cielo. "

    
risposta data 04.04.2014 - 21:30
fonte
8

Questo è sempre un compromesso.

In primo luogo, l'industria informatica parla di soldi alla fine. Quello che devi fare come sviluppatore è generare valore per il cliente in modo da ottenere denaro (è una semplificazione eccessiva ma il punto principale è qui).

Il tempo dello sviluppatore costa denaro. Anche l'energia della macchina costa denaro. Di solito, questo secondo costo è molto più basso del primo. Quindi, questo è il capitale per avere un codice leggibile e un codice gestibile, in modo che lo sviluppatore possa impiegare la maggior parte del tempo a fornire valore.

La micro-ottimizzazione può, in alcuni casi, essere importante. Ma di solito implicano codice meno leggibile o codice meno estensibile (questo non è il caso del tuo esempio collegato, ma in generale lo è). Questo costerà a un certo punto il tempo dello sviluppatore. Questa volta è più costoso della potenza della macchina, questo è uno spreco.

In secondo luogo, la micro-ottimizzazione in un grande progetto può rendere sempre più difficile mantenere / evolvere. Il problema è che quando si evolve, qualche altra ottimizzazione potrebbe essere ora impossibile da fare. Con un'applicazione in evoluzione, in genere ti ritroverai con una soluzione che è più lenta di quella che avresti avuto senza fare quelle ottimizzazioni.

In terzo luogo, l'ottimizzazione è spesso irrilevante in quanto la complessità dell'algoritmo generalmente supererà qualsiasi micro-ottimizzazione che avresti potuto fare se il set di dati crescesse. Purtroppo, poiché la micro-ottimizzazione rende il tuo codice più difficile da mantenere / evolvere, l'ottimizzazione potrebbe essere più difficile da fare.

A volte, il valore è in questa ottimizzazione (si pensi ai programmi critici di latenza, come nei videogiochi o al pilota automatico di un aereo). Ma questo deve essere dimostrato. Di solito il tuo programma trascorre la maggior parte del tempo in una porzione limitata di codice. Qualunque sia la tua micro-ottimizzazione, non otterrai mai i tuoi programmi più velocemente senza identificare il collo di bottiglia e lavorare su questa parte.

Chiedendo la tua domanda come hai fatto, hai dimostrato di non aver confrontato il problema su un programma reale. In questo caso, avresti potuto fare il trucco e notato se fosse più veloce o meno. Quindi lo stavi chiedendo prima di avere qualche problema. Questo è dove il problema è. Stavi gestendo il problema dell'ottimizzazione nel modo sbagliato.

Poiché la manutenzione e l'evoluzione di solito sono più preziose della micro-ottimizzazione, assicurati di avere l'interfaccia giusta prima di fare qualsiasi. Quindi, se parti del tuo programma sono abbastanza astratte l'una per l'altra, puoi ottimizzarne l'una senza rovinare tutto. Ciò richiede che la tua interfaccia sia in esecuzione abbastanza a lungo da essere attendibile.

    
risposta data 08.08.2011 - 20:25
fonte
7

I tempi degli sviluppatori costano più del tempo del computer. Di solito è ciò che desideri ottimizzare. ma

  • C'è una differenza tra micro-ottimizzazione e complessità algoritmica. Dedica abbastanza tempo per essere sicuro di utilizzare l'algoritmo giusto .
  • Assicurati di porre la domanda giusta, select (select count(*) from foo) >= 1 non è la stessa cosa di select exists(select 1 from foo) .
  • alcuni idiomi linguistici sono popolari semplicemente perché sono più veloci, è giusto usarli, dal momento che molti utenti fluenti della lingua avranno familiarità con loro. (il tuo esempio è un buon esempio).
risposta data 08.08.2011 - 21:46
fonte
7

Le prestazioni sono una caratteristica

L'articolo di Jeff Atwood è eccezionale sulla costruzione di un sito Web ad alte prestazioni e sull'importanza di farlo ...

Detto questo, non concentrarti sulla micro-ottimizzazione finché non ne hai bisogno. È possibile ottimizzare i costi in modo più vantaggioso. Concentrati sull'architettura, non sul codice. La maggior parte dei siti web che ho visto che hanno funzionato lentamente aveva problemi di alto livello (livello di servizio Web non necessario, progettazione di database scadente, architetture eccessivamente complicate) che non solo influivano negativamente sulle prestazioni, ma erano profondamente radicati e difficili da risolvere.

Durante la creazione di un sito Web, il codice lato client e la logica del database hanno maggiori probabilità di causare problemi di prestazioni rispetto al codice lato server. Ad ogni modo, però, se hai problemi di prestazioni lo saprai, potrai anche profilare un profilo migliore del tuo codice e trovarli presto.

    
risposta data 09.08.2011 - 00:55
fonte
7

Che cosa vuoi ottimizzare?

  • Prestazioni del software?
  • L'affidabilità?
  • Produttività del programmatore?
  • Soddisfazione del cliente?
  • Efficienza energetica?
  • Maintainability?
  • Time to market?
  • Costo?

"Ottimizza" non significa sempre far funzionare il codice il più velocemente possibile. Ci sono momenti in cui trovare il modo più veloce in assoluto per fare qualcosa è importante, ma in realtà non è tutto ciò che è comune nella maggior parte del codice. Se gli utenti non riescono a notare la differenza tra 50 e 100 microsecondi, non c'è alcuna differenza tra i due in codice che vengono eseguiti solo occasionalmente. Ecco un esempio:

Se è necessario aggiornare continuamente una visualizzazione della lunghezza dell'input dell'utente e la quantità di tempo che impiega una delle due routine per determinare che la lunghezza sia molto più piccola del tempo tra due sequenze di tasti consecutivi, in realtà non importa quale routine usi. D'altra parte, se è necessario determinare la lunghezza di un miliardo di stringhe, probabilmente si vorrà prestare molta attenzione alle differenze di prestazioni tra le diverse routine. Nel primo caso, potresti preferire scrivere un codice che sia facile da capire e verificare; nel secondo caso, potresti essere disposto a negoziare la leggibilità per la velocità.

In ogni caso, se hai intenzione di ottimizzare il tuo codice, dovresti profilare il tuo codice prima e dopo eventuali modifiche apportate. I programmi in questi giorni sono abbastanza complicati da rendere spesso difficile stabilire dove si trovano i colli di bottiglia; la creazione di profili ti aiuta a ottimizzare il codice corretto e quindi a mostrare che le ottimizzazioni apportate hanno funzionato davvero.

Non hai detto quando tuo padre è andato in pensione o che tipo di programmazione ha fatto, ma la sua reazione non è sorprendente. Storicamente, la memoria, la memoria secondaria e il tempo di elaborazione erano tutti costosi e talvolta molto costosi. In questi giorni, tutte queste cose sono diventate molto economiche rispetto al tempo del programmatore. Allo stesso tempo, processori e compilatori sono diventati in grado di ottimizzare il codice in modi che i programmatori non potrebbero mai eguagliare. I giorni in cui i programmatori usano piccoli trucchi per imparare alcune istruzioni della macchina qui e ce ne sono quasi tutte sparite.

    
risposta data 09.08.2011 - 04:02
fonte
7

Non è importante ottimizzare il micro durante la scrittura del codice. L'ottimizzazione dovrebbe essere fatta con l'aiuto di un profiler, ottimizzando il codice dove conta.

TUTTAVIA , un programmatore dovrebbe cercare di evitare di fare cose ovviamente stupide durante la scrittura del codice.

Ad esempio, non effettuare operazioni costose ripetute all'interno di un ciclo. Memorizza il valore in una variabile fuori dal ciclo e usalo. Non fare cose come confronti tra stringhe o regex più e più volte in una funzione spesso chiamata, quando puoi salire di livello, eseguire il confronto e trasformarlo in un numero intero o un riferimento di funzione o una classe derivata.

Queste cose sono facili da ricordare per un programmatore esperto e quasi sempre migliorano la qualità del codice.

    
risposta data 10.08.2011 - 18:25
fonte
7

Quando decidi cosa ottimizzare, ricorda sempre la legge di Amdahl . Vedi il link per matematica precisa; la frase concisa da ricordare è:

If one part of your program accounts for 10% of its runtime, and you optimize that part to run twice as fast, the program as a whole will only speed up by 5%.

Questo è il motivo per cui le persone dicono sempre che non vale la pena di ottimizzare parti del tuo programma che non occupano più di una piccola percentuale del runtime totale. Ma questo è solo un caso speciale di un principio più generale. La legge di Amdahl ti dice che se hai bisogno di far funzionare l'intero programma due volte più velocemente, devi accelerare ogni pezzo di una media del 50%. Ti dice che se hai bisogno di elaborare venti gigabyte di dati, ci sono solo due modi per farlo andare più veloce del tempo necessario per leggere venti gigabyte dal disco: ottieni un disco più veloce o riduci i dati.

Quindi cosa dice la legge di Amdahl sulle micro-ottimizzazioni? Dice che forse valgono la pena se si applicano su tutta la linea. Se riesci a radere un percento del runtime di ogni funzione del tuo programma, congratulazioni! Hai velocizzato il programma dell'1%. Vale la pena farlo? Beh, come compilatore sarei lieto di trovare un'ottimizzazione che lo ha fatto, ma se lo fai a mano, direi cercare qualcosa di più grande.

    
risposta data 06.09.2014 - 18:42
fonte
6

Dipende dal livello di sviluppo in cui ti trovi, quando inizialmente inizi a scrivere qualcosa, le micro-ottimizzazioni non dovrebbero essere una considerazione in quanto otterrai più guadagni in termini di prestazioni usando algoritmi buoni di quelli che usi micro ottimizzazioni. Inoltre, considera ciò che stai sviluppando poiché le applicazioni sensibili al tempo vedranno più vantaggi dalle considerazioni di ottimizzazione micro rispetto alle applicazioni aziendali generiche.

Se stai testando ed estendendo software, le micro-ottimizzazioni probabilmente ti faranno male, tendono a rendere il codice più difficile da leggere e persino a introdurre il loro set unico di bug che devono essere corretti insieme a qualsiasi altra cosa che deve essere risolta.

Se in realtà stai ricevendo lamentele da parte degli utenti riguardo al codice lento, potrebbero valerne la pena, ma solo se tutto il resto è stato risolto, ovvero:

  • Il codice è scritto bene?
  • L'applicazione è in grado di accedere ai suoi dati senza problemi?
  • È possibile utilizzare un algoritmo migliore?

Se tutte queste domande hanno tutte risposta e si verificano ancora problemi di prestazioni, potrebbe essere il momento di iniziare a utilizzare le micro-ottimizzazioni nel codice, ma le probabilità sono che altre modifiche (ad es. codice migliore, algoritmo migliore, ecc.) stiano andando per ottenere un guadagno maggiore in termini di prestazioni rispetto a una micro-ottimizzazione.

    
risposta data 28.06.2012 - 00:55
fonte
5

La velocità di esecuzione è uno dei molti fattori che contribuiscono alla qualità di un programma. Spesso, la velocità ha una correlazione inversa con la leggibilità / manutenibilità. In quasi tutti i casi, il codice deve essere leggibile dall'uomo in modo che il codice possa essere mantenuto. L'unica volta che la leggibilità può essere compromessa è quando la velocità è un requisito essenziale. L'obbligo di rendere il codice più veloce della piena leggibilità / manutenibilità non è quasi mai applicabile, ma ci sono alcuni casi in cui lo farà. La cosa principale da ricordare è che il codice micro-ottimizzato è spesso un codice hacky, quindi a meno che non vi sia un requisito definito da qualche parte, è quasi sempre il modo sbagliato per risolvere il problema. Ad esempio, l'utente non noterà quasi mai la differenza tra i tempi di esecuzione di 0,5 secondi e 1 secondo nelle operazioni CRUD, quindi non è necessario entrare in un assembly-interop-hackfest per arrivare a questo 0,5 secondi. Sì, potrei far volare un elicottero per lavoro e sarebbe 10 volte più veloce, ma non a causa del prezzo e del fatto che l'elicottero è molto più difficile da pilotare. Quando esegui il micro-ottimizzazione del codice inutilmente, questo è esattamente quello che stai facendo: aggiungere complessità e costi inutili per raggiungere un obiettivo superfluo.

    
risposta data 08.08.2011 - 18:58
fonte
5

La micro-ottimizzazione è importante quando si colpisce un vincolo. La cosa che ti interessa potrebbe essere la memoria, potrebbe essere la velocità effettiva, potrebbe essere la latenza, o potrebbe essere il consumo di energia. Si noti che queste sono caratteristiche a livello di sistema; non è necessario (e non è possibile) ottimizzare ogni funzione in ogni modo.

È più probabile che i sistemi integrati necessitino di micro-ottimizzazione perché i vincoli vengono colpiti più facilmente. Tuttavia, anche lì la micro-ottimizzazione ti porta solo lontano; non è possibile ottimizzare la micro-ottimizzazione per uscire da un cattivo progetto. Il punto sul buon design in un sistema è che puoi ragionare sul sistema nel suo insieme. I componenti che necessitano di micro-ottimizzazione dovrebbero essere ben esposti e ottimizzati in modo da non compromettere il design del sistema.

Nota che i piccoli sistemi "incorporati" oggi possono essere molto vicini a Vaxen o PDP-11s di ieri, quindi questi problemi erano più comuni. In un moderno sistema per scopi generali che fa moderno calcolo commerciale generale, la micro-ottimizzazione è rara. Questo probabilmente fa parte del motivo per cui tuo padre prende la posizione che fa.

Tuttavia, non importa se hai a che fare con nanosecondi, millisecondi, secondi o ore; i problemi sono gli stessi. Devono essere valutati nel contesto del sistema e cosa stai cercando di ottenere.

Questo è un esempio di una recente domanda che ho risposto su Stack Overflow per un caso in cui era necessaria la micro-ottimizzazione: Encoder video open source per un sistema incorporato .

    
risposta data 23.05.2017 - 14:40
fonte
4

Il più grande problema con la micro-ottimizzazione è che ti porta a scrivere un codice più difficile da mantenere.

Un altro problema dipende dalla configurazione del computer, a volte la tua micro-ottimizzazione potrebbe avere le peggiori prestazioni che senza l'ottimizzazione.

Fare molti micro-ottimizzazione ti consuma molto tempo a combattere contro qualcosa che non conta davvero.

Un approccio migliore consiste nel creare un codice più pulito, più facile da mantenere e, in caso di problemi di prestazioni, si esegue un profilo per capire cosa rende veramente lento il codice. E sapendo esattamente cosa è veramente male puoi sistemarlo.

Non sto dicendo che non fare micro-ottimizzazioni sia una scusa per scrivere codice stupido.

    
risposta data 08.08.2011 - 18:47
fonte
4

Se inizi a preoccuparti di millisecondi, dovresti considerare di rinunciare a PHP e usare invece C o Assembly. Non che io voglia farlo, non ha senso discutere di questi numeri e usare un linguaggio di scripting. Il tuo codice itera con questo comando che spesso comunque?

I fattori ambientali sono fuori discussione qui, quei server funzionano comunque 24 ore su 24 e se effettivamente elaborano qualcosa sarebbe importante se si tratta di un compito in esecuzione da molto tempo.

Molto probabilmente la luce nel tuo ufficio e l'energia che i nostri computer utilizzavano mentre stavamo scrivendo domande e risposte, consumavano molta più energia di qualsiasi tipo di micro ottimizzazione che puoi ragionevolmente applicare alle tue applicazioni, per sempre.

    
risposta data 08.08.2011 - 19:13
fonte
4

Dovresti scegliere il migliore, semplice algoritmo per l'attività. La ragione per cui deve essere semplice è mantenere il codice leggibile. Il motivo per cui deve essere il migliore è evitare di iniziare con cattive caratteristiche di runtime. Non scegliere ciecamente BubbleSort quando sai che avrai grandi set di dati. Va bene, tuttavia, per la specie occasionale di 10 elementi.

THEN, se i numeri di profilo mostrano che la scelta del migliore, l'algoritmo semplice non era abbastanza buono, puoi iniziare l'ottimizzazione (che di solito è il costo della leggibilità).

    
risposta data 10.08.2011 - 16:11
fonte
4

L'ho già detto prima, e lo dirò qui: "L'ottimizzazione prematura è la radice di tutti i mali" . Questa dovrebbe essere una delle regole al centro della mente di ogni programmatore.

Il codice può, a un certo punto, essere sempre più veloce di quello che è attualmente. A meno che tu non stia assemblando a mano con un particolare chip in mente, c'è sempre qualcosa da guadagnare attraverso l'ottimizzazione. Tuttavia, a meno che tu non voglia essere un assemblaggio a mano per tutto quello che fai, ci deve essere un obiettivo quantitativo, che una volta che incontri, dici "è abbastanza" e smetti di ottimizzarlo, anche se c'è ancora uno sguardo appariscente tu in faccia.

Il codice bello, elegante ed estremamente performante è inutile se non funziona (e per "lavoro" intendo produrre l'output atteso dato tutti gli input previsti). Pertanto, produrre codice che funzioni dovrebbe SEMPRE essere la prima priorità. Dopo il suo funzionamento, valuti le prestazioni e, se manca, cerchi modi per migliorarlo, fino al punto in cui è abbastanza buono.

Ci sono alcune cose che devi decidere in anticipo che avranno un impatto sulle prestazioni; decisioni basilari come la lingua / runtime che utilizzerai per implementare questa soluzione. Molti di questi influenzeranno le prestazioni di molti ordini di grandezza più che chiamare un metodo rispetto all'altro. Onestamente, PHP, come linguaggio di scripting, è già un successo in termini di prestazioni, ma visto che pochi siti script sono costruiti dal basso verso l'alto in C / C ++, è paragonabile alle altre tecnologie che probabilmente sceglieresti (Java Servlet, ASP.NET , ecc.)

Dopodiché, la dimensione del messaggio I / O è il prossimo killer delle prestazioni. Ottimizzare ciò che leggi e scrivi sul disco rigido, sulle porte seriali, sulle pipe di rete, ecc. Di solito migliorerà il tempo di esecuzione del programma di molti ordini di grandezza anche se gli algoritmi che stanno dietro le operazioni di I / O sono efficienti. Dopodiché, riduci la complessità Big-O dell'algoritmo stesso, e se è assolutamente necessario, puoi "micro-ottimizzare" scegliendo le chiamate al metodo meno costose e prendendo altre decisioni esoteriche a livelli bassi.

    
risposta data 11.08.2011 - 00:38
fonte
4

Hai detto che tuo padre è un programmatore in pensione. I programmatori che hanno lavorato nel mondo mainframe dovevano essere molto preoccupati per le prestazioni. Ricordo di aver studiato un'attività della US Navy in cui il loro mainframe era vincolato all'hardware con 64 KB di memoria per utente. In quel mondo di programmazione devi tirare fuori ogni piccola parte che potresti.

Le cose ora sono molto diverse e la maggior parte dei programmatori non ha bisogno di preoccuparsi così tanto delle micro-ottimizzazioni. Tuttavia, i programmatori di sistemi incorporati continuano a farlo e le persone del database hanno ancora molto bisogno di utilizzare il codice ottimizzato.

    
risposta data 04.04.2014 - 21:45
fonte
3

Il codice dovrebbe essere scritto per essere assolutamente chiaro su ciò che fa. Quindi, se e solo se è troppo lento, torna indietro e velocizzalo. Il codice può sempre essere modificato per essere più veloce in seguito, se può essere compreso, ma buona fortuna cambiandolo per essere chiaro se è veloce.

    
risposta data 08.08.2011 - 19:10
fonte
3

È importante se:

1) La vita di qualcuno dipende dal tuo codice. Una funzione che richiede 25 ms per l'esecuzione nel cardiofrequenzimetro di qualcuno è probabilmente una cattiva idea.

Personalmente ho un approccio a due punte: ci sono micro-ottimizzazioni che puoi fare che non influenzano la leggibilità, ovviamente vuoi usarle. Ma se influisce sulla leggibilità, tieni a bada: non otterrai molti vantaggi e in realtà potrebbe richiedere più tempo per eseguire il debug a lungo termine.

    
risposta data 09.08.2011 - 00:41
fonte
3

Is micro-optimisation important when coding?

No, dato che esistono piattaforme come JVM e . NET dove il codice è scritto per una macchina virtuale e quindi cercando di ottimizzare l'esecuzione potrebbe non funzionare così bene come ciò che è ottimale sul desktop di uno sviluppatore non è necessariamente lo stesso su un server. Guardate quanto lontano dall'hardware alcuni di questi pezzi di software di alto livello sono per un altro punto qui. Qualcosa da considerare è data la diversità dell'hardware, quanto è realistico ottimizzare il codice per specifici chip come CPU o GPU quando un nuovo modello uscirà probabilmente in meno di un anno?

Un'altra questione da considerare è la prestazione misurata in base a quale metrica: velocità di esecuzione, memoria utilizzata nell'esecuzione, velocità di sviluppo di nuove funzionalità, dimensioni del codice di base su un server in moduli compilati o decompilati, scalabilità, manutenibilità, ecc.? Se presa abbastanza in generale, la domanda diventa banale, ma non sono sicuro di quanto intendessi in generale interpretare le prestazioni in quanto può essere quasi tutto purché possa essere misurato in qualche modo.

Alcune micro-ottimizzazioni potrebbero funzionare e alcuni potrebbero non funzionare, il che è il motivo per cui ci si può chiedere quanto valga la pena svolgere tale lavoro rispetto ad altri lavori che possono essere considerati molto più prioritari come nuove funzionalità o bug di correzione. L'altra domanda sarebbe se un aggiornamento dell'hardware o del software potrebbe interrompere anche alcune di quelle ottimizzazioni.

    
risposta data 04.04.2014 - 21:26
fonte
1

Penso che ci sia una grande differenza tra una buona programmazione e una micro-ottimizzazione.

Se ci sono due modi per fare lo stesso compito, uno è più veloce dell'altro ed entrambi hanno la stessa leggibilità, dovresti usare il più veloce. Sempre. E questa è una buona programmazione. Non c'è motivo di non utilizzare un algoritmo migliore per risolvere un problema. E persino documentarlo è semplice: dai il nome dell'algoritmo, tutti potranno google e trovare maggiori informazioni su come funziona.

E i buoni algoritmi sono già ottimizzati. Saranno veloci. Saranno piccoli. Utilizzeranno la memoria minima richiesta.

Anche se li usi, il tuo programma non ha ancora quella prestazione, puoi considerarlo come micro-ottimizzazione. E dovrai veramente conoscere la lingua per essere in grado di ottimizzare il micro.

E c'è sempre spazio per spendere un po 'di più sull'hardware. L'hardware è economico, i programmatori sono costosi . Non spendere troppo tempo / denaro ottimizzando quando puoi semplicemente acquistare l'hardware.

    
risposta data 09.08.2011 - 14:08
fonte
1

La leggibilità del codice di IMHO è più importante della micro-ottimizzazione perché nella maggior parte dei casi la micro-ottimizzazione non vale la pena.

Articolo sulle micro-ottimizzazioni senza senso :

As most of us, I am tired to read blog posts about non-sense micro-optimizations like replacing print by echo, ++$i by $i++, or double quotes by single quotes. Why? Because 99.999999% of the time, it is irrelevant. Why? Because 99.99% of the time, you'd better install a PHP accelerator like APC, or add these missing indexes on your database columns, or try to avoid those 1000 database requests you have on the homepage.

print uses one more opcode because it actually returns something. We can conclude that echo is faster than print. But one opcode costs nothing, really nothing.

I have tried on a fresh WordPress installation. The script halts before it ends with a "Bus Error" on my laptop, but the number of opcodes was already at more than 2.3 millions. Enough said.

Quindi nella maggior parte dei casi la micro-ottimizzazione consente di risparmiare 1 operazione su milioni, ma peggiora la leggibilità.

    
risposta data 30.07.2012 - 20:05
fonte
1

Altre risposte sono giuste sul denaro. Ma aggiungerò un altro punto in cui bisogna differenziare cosa è l'ottimizzazione prematura / micro-ottimizzazione e scrivere codice performante che riflette una comprensione del comportamento dei costrutti linguaggio / struttura (mi dispiace, non ho trovato una parola per l'ultima). L'ultima è una buona pratica di codifica e generalmente si dovrebbe fare!

Spiegherò. La cattiva ottimizzazione (leggi prematura / micro ottimizzazione) non avviene quando si ottimizzano sezioni di codice senza profiling per sapere se sono davvero i colli di bottiglia. È quando si ottimizza in base a presupposti, opinioni e comportamenti non documentati. Se è documentato e fa qualcosa in modo più efficiente / logico per quanto piccolo, lo chiamo buona ottimizzazione . Come altri hanno affermato, entrambi hanno contro e quasi nessun professionista per quanto riguarda il guadagnare buoni affari, ma io continuo a fare il secondo, non il primo, se non totalmente sconfitta leggibilità. Sì, la leggibilità / manutenibilità è della massima importanza e riguarda il punto in cui si disegna la linea.

Ripeterò i punti fatti da altri qui come l'inutilità delle ottimizzazioni sia buone che cattive:

  1. Le tue dipendenze da un problema specifico possono cambiare e qualsiasi tempo dedicato all'ottimizzazione di prima di completare la sezione logica della tua applicazione è una perdita di tempo. Intendo ottimizzare in una fase relativamente iniziale. Oggi hai un List<T> e nel momento in cui la tua app viene spedita devi cambiarlo in LinkedList<T> e ora tutto il benchmarking era uno spreco di tempo e fatica.

  2. Per lo più il vero collo di bottiglia della tua applicazione (letto come differenza misurabile) potrebbe essere il 5% del tuo codice (principalmente quelli di sql) e l'ottimizzazione del restante 95% non dà alcun vantaggio ai tuoi clienti.

  3. Di solito, "tecnicamente" un codice con prestazioni migliori significa maggiore verbosità che a sua volta significa più codice soggetto a errore che a sua volta significa maggiore manutenibilità e più tempo trascorso che a sua volta significa guadagnare meno.

  4. L'impronta di carbonio che salvi per tutto il mondo con un guadagno di prestazioni dell'1% è facilmente sminuita dai gas a effetto serra che il tuo team dovrà emettere al momento del debug e mantenendo tale codice.

I negativi di ottimizzazione errata in particolare sono:

  1. Spesso non ti dà le prestazioni che ti aspetti. Leggi questa domanda su SO, dove le ottimizzazioni sono andate male . In effetti può avere effetti negativi. Questo è il problema con il comportamento non documentato.

  2. I compilatori più moderni lo faranno comunque per te.

Fornirò alcuni esempi di ottimizzazione brutta e buona:

Il cattivo -

  1. uso di tipi interi più piccoli invece di Int32 .

  2. ++i utilizzato al posto di i++

  3. for invece di foreach (il peggiore che ho visto, totalmente sconfigge la logica)

  4. evitando le variabili chiuse

    string p;
    foreach (var item in collection)
        p = ...;
    
  5. utilizzando char invece di stringa durante la concatenazione di stringhe, ad esempio:

    string me = 'i' + "me myself"; // something along that line - causes boxing
    

Il buono (dal mondo .NET. Dovrebbe essere auto-esplicativo) -

  1. Ricerca doppia

    if (Dictionary<K, V>.TryGetValue(K, out V))
        do something with V
    

    invece di

    if (Dictionary<K, V>.ContainsKey(K))
        do something with Dictionary<K, V>[K]
    
  2. Carica tutti

    DirectoryInfo.EnumerateFiles();
    

    invece di

    DirectoryInfo.GetFiles();
    
  3. Casting a due fasi:

    s = o as string;
    if (s != null)
        proceed
    

    invece di

    if (o is string)
        s = (string)o;
    
  4. Se l'ordine non ha importanza

    if (counter < X || expensiveFunction())
    

    invece di

    if (expensiveFunction() || counter < X)
    
  5. Pugilato

    void M<T>(T o) //avoids boxing
    {
    
    }
    

    invece di

    void M(object o)
    {
    
    }
    

Se mi chiedi se questi offrono notevoli vantaggi in termini di prestazioni, direi di no. Ma suggerirei che uno dovrebbe usarli perché deriva da una comprensione del comportamento di questi costrutti. Perché fare due chiamate quando puoi fare solo 1? Da un punto di vista filosofico la sua buona pratica di codifica. E 1 & 3 sono leggermente meno leggibili anche in termini rigorosi, ma superano la leggibilità? No, non molto, quindi uso. Questa è la chiave, mantenendo un buon rapporto prestazioni / leggibilità. E quando è così, è su dove si disegna la linea.

    
risposta data 23.05.2017 - 14:40
fonte
1

"Ne vale la pena" ha bisogno di un contesto, come quanto è più semplice scrivere, leggere e gestire e quanto più velocemente rende qualcosa al utente notevolmente più reattivo , interattivo, richiedendo meno tempo per loro di aspettare.

Risparmiare pochi centesimi per acquistare una lattina di soda non mi farà molto bene se devo percorrere una distanza per risparmiare quei centesimi, soprattutto dato che di questi tempi non bevo quasi mai la soda. Risparmiare qualche soldino per barattolo su un acquisto di un milione di lattine di bibite potrebbe essere un grosso problema.

Nel frattempo risparmiamo pochi centesimi quando due persone sono proprio accanto a me e uno offre la stessa identica cosa per pochi centesimi in meno e l'altro no, e scelgo quello più costoso perché mi piace che il loro cappello sia migliore un caso folle di pessimizzazione.

Quello che spesso trovo le persone che chiamano "micro-ottimizzazioni" sembrano essere curiosamente prive di misurazioni, contesto e discussioni da parte dell'utente, quando dovrebbero essere tutte e tre le cose da considerare tali ottimizzazioni se non sono banali da applicare . Per me un corretto micro-ottimizzazione in questi giorni si riferisce a cose come layout di memoria e pattern di accesso, e mentre potrebbero sembrare "micro" a fuoco, non hanno effetto micro.

Sono riuscito, non molto tempo fa, a ridurre un'operazione da 24 secondi a 25 millisecondi (circa 960 volte più veloce), con uscite identiche (garantite da test automatici), senza modifiche alla complessità algoritmica, per diffusione volumetrica del calore skinning, attraverso "micro-ottimizzazioni" (il più grande dei quali derivava da un cambiamento di layout della memoria che lo portò a circa 2 secondi, il resto erano cose come SIMD e ulteriori analisi delle mancate cache in VTune e qualche ulteriore riorganizzazione della memoria disposizione).

Wolfire spiega la tecnica qui, e ha lottato con il tempo richiesto: link

La mia implementazione è riuscita a essere in grado di farlo in millisecondi, mentre si sforzava di ridurlo a meno di un minuto:

Dopoaverlo"ottimizzato per micro" da 24 secondi a 25 ms, questo era un punto di svolta nel flusso di lavoro. Ora gli artisti possono cambiare i loro impianti in tempo reale a oltre 30 FPS senza attendere 24 secondi ogni volta che apportano qualche piccolo cambiamento al loro impianto. E questo ha effettivamente cambiato l'intero design del mio software, dal momento che non avevo più bisogno di barra di progresso e cose del genere, ma tutto è diventato interattivo. Quindi potrebbe essere una "micro-ottimizzazione" nel senso che tutti i miglioramenti sono venuti senza alcun miglioramento della complessità algoritmica, ma in effetti è stata piuttosto una "mega-ottimizzazione" che ha reso quello che prima era un processo doloroso e non interattivo in tempo reale, interattivo, che ha completamente cambiato il modo in cui gli utenti hanno lavorato.

Misurazione, requisiti di fine utente, contesto

Mi è piaciuto molto il commento di Robert qui e forse non sono riuscito a esprimere il punto che volevo:

Well, c'mon. Nobody is going to argue that this kind of change isn't "worth it." You were able to demonstrate a tangible benefit; many so-called micro-optimizations cannot.

Questo, nonostante si lavori in un campo molto critico per le prestazioni con requisiti spesso in tempo reale, l'unica volta che considero una micro-ottimizzazione che richiede di andare fuori dai miei schemi.

E vorrei sottolineare non solo le misurazioni, ma il lato utente di esso. Sono uno strano in quanto sono arrivato al mio attuale campo (e precedentemente gamedev) come utente / fan prima, sviluppatore secondo. Quindi non sono mai stato così eccitato dalle solite cose che entusiasmano i programmatori come risolvere enigmi tecnici; Li ho trovati un peso, ma li avrei sopportati attraverso il sogno dell'utente che condividevo con altri utenti. Ma questo mi ha aiutato a essere sicuro che se stavo ottimizzando qualcosa, avrebbe un impatto reale sugli utenti con reali benefici. È la mia salvaguardia contro la micro-ottimizzazione senza scopo.

Questo è tanto importante quanto il profiler a mio parere, perché avevo colleghi che facevano cose come la micro-ottimizzazione della suddivisione di un cubo in un miliardo di sfaccettature solo per soffocare su modelli di produzione reali come personaggi e veicoli. Il loro risultato è stato impressionante in alcuni "tech demo", ma quasi inutile per gli utenti effettivi, perché stavano profilando e misurando e confrontando casi non allineati con casi d'uso reali. Quindi è molto importante capire prima cosa è importante per gli utenti, sia imparando a pensare e utilizzare il software come uno o collaborando con loro (idealmente entrambi, ma almeno collaborando con loro). La cosa più importante per me, se vogliamo ottenere micro e iniziare i cicli di rasatura e fallire nella cache e così via, è iniziare a diventare veramente bravo a dare priorità a dove andare per farlo (che naturalmente corrisponde alla conoscenza di tutti i posti che non dovremmo Fallo, per il quale sia la comprensione del profiler che quella dell'utente sono molto importanti).

    
risposta data 21.12.2018 - 04:34
fonte
0

La metterò in questo modo - la micro-ottimizzazione è un processo di ottimizzazione di qualcosa che non è affatto un collo di bottiglia. Ad esempio, se il tuo programma chiama due funzioni A e B, e A richiede 100 millisecondi per completare e B richiede 2 microsecondi, e tu continui ad ottimizzare la funzione B. Questo non è solo non importante, è assolutamente sbagliato. Ma l'ottimizzazione della funzione B si chiama ottimizzazione e non micro-ottimizzazione. L'importanza dell'ottimizzazione dipende. Di 'che non hai nient'altro da fare e il tuo programma è privo di bug, quindi sì, è importante. Ma generalmente hai priorità. Diciamo che è necessario aggiungere / scrivere la funzione C. Se si pensa che la funzione di scrittura C ti farà guadagnare più denaro rispetto a rendere il tuo programma più veloce senza quella funzionalità, allora vai per l'ottimizzazione. Altrimenti perseguire la funzionalità. Inoltre, i programmatori esperti focalizzati sulle prestazioni non passano molto tempo ad ottimizzare, scrivono solo programmi veloci. Almeno loro sanno quali strumenti usare e cosa fare per non spendere anni facendo ottimizzazioni senza senso (leggi micro).

    
risposta data 10.08.2011 - 19:45
fonte

Leggi altre domande sui tag