La chiarezza del codice uccide le prestazioni dell'applicazione?

Dato che il codice di oggi sta diventando più complesso di minuto in minuto, il codice deve essere progettato per essere gestibile, il che significa che è facile da leggere e facile da capire.La chiarezza del codice uccide le prestazioni dell'applicazione?

Detto questo, non posso fare a meno di ricordare i programmi eseguiti un paio di anni fa come Winamp o alcuni giochi in cui era necessario un programma ad alte prestazioni perché il tuo 486 100 Mhz non avrebbe riprodotto gli mp3 con quello bellissimo lettore mp3 che ha consumato tutti i tuoi cicli della CPU.

Ora eseguo Media Player (o qualsiasi altra cosa), inizio a riprodurre un mp3 e mangia un 25-30% di uno dei miei quattro core. Dai!! Se un 486 può farlo, come può la riproduzione occupare così tanto processore da fare lo stesso?

Sono uno sviluppatore anch'io, e ho sempre avuto l'abitudine di consigliare: mantieni il tuo codice semplice, non ottimizzarlo prematuramente per le prestazioni. Sembra che siamo passati dal "tentativo di ottenere il minor numero di CPU possibile" a "se non ci vuole troppo CPU va bene".

Quindi, pensi che stiamo uccidendo le prestazioni ignorando le ottimizzazioni?

fonte

2009-07-22 Jorge Córdoba

Dubito che la chiarezza del codice sia il problema con Media Player. –

Anche se penso che questa potrebbe essere una domanda interessante a cui rispondere, trovo un po 'sconcertante che la prima ipotesi sul perché un'applicazione sia lenta è dovuta agli sviluppatori che scrivono codice chiaro. :) In generale, però, penso che molte persone attribuiscono un generale "software gonfiato" (un termine piuttosto ambiguo) alla lentezza di alcune applicazioni moderne. – Falaina

Non intendo la causa, ma ovunque (compreso lo stackoverflow) qualcuno mi chiede, dovrei usare questo o quello per migliorare le prestazioni? La risposta è, quasi sempre, "no, non preoccuparti delle prestazioni finché non ci sono problemi". Quindi consideriamo le prestazioni solo come un bug, mai come una caratteristica ... –

Il codice pulito non elimina le prestazioni. Il codice errato uccide le prestazioni.

fonte

2009-07-22 23:36:03

Ben messo. Un algoritmo pulito supererà un algoritmo cattivo "sintonizzato". Quando si tratta di applicazioni GUI, alcuni sviluppatori non capiscono come sono assemblate le interfacce utente basate su dati ed eventi e le alternative "forza bruta" si traducono in ciò che state descrivendo. Non è la chiarezza del codice, è il codice ingenuità. –

Personalmente, mi sforzo sempre per un equilibrio tra prestazioni e manutenibilità. Siamo lontani dai tempi in cui i tempi della CPU erano costosi ei programmatori erano economici, ma come utente e sviluppatore, è frustrante trovare le stesse attività che richiedono più tempo per le versioni più recenti dello stesso software in esecuzione su più recenti, più veloci hardware ... Quindi, soggettivamente, sì, penso che alcune aziende siano andate troppo oltre nella direzione opposta.

fonte

2009-07-22 23:38:31 Adrien

Penso che la prestazione sia correlata alla manutenibilità, non contraria. –

Per la maggior parte, sì, ma quello che stavo ottenendo (male) era più simile a quello che hai indicato nella tua risposta; Ho visto il codice "super-gestibile" che non era solo lento, ma, almeno per me, più difficile da seguire. Come ho detto, "equilibrio". Per utilizzare in modo improprio la regola 80/20, la maggior parte delle app non ha bisogno delle massime prestazioni, ma, poiché l'orientamento agli oggetti è diventato onnipresente, le applicazioni sono diventate (dal punto di vista dell'utente, almeno) più lente e gonfie, mentre l'hardware le velocità continuano a migliorare. Da dove viene la disparità delle prestazioni? – Adrien

Gli sviluppatori non dovrebbero avere paura di ottimizzare le loro applicazioni. La lentezza e la lentezza delle app di oggi sono spaventose.

fonte

2009-07-22 23:39:32

++ Non ripetere ripetizioni ripetitive ridondanti, ma hai ragione. http://stackoverflow.com/questions/926266/performance-optimization-strategies-of-last-resort/927773#927773 –

Gli sviluppatori dovrebbero avere paura di ottimizzare. Le ottimizzazioni devono essere prioritarie insieme a tutto ciò che deve essere fatto, come più/migliori funzionalità, correzioni di bug, test di usabilità, ecc. Gli sviluppatori non dovrebbero essere quelli che prendono la decisione di ottimizzare, a meno che non siano anche il proprietario del prodotto. – nicholaides

Le ottimizzazioni dopo il fatto devono essere prioritarie insieme a tutto il resto, ma le ottimizzazioni dovrebbero sempre essere implementate come sviluppatore come linea di condotta standard. Non dovremmo scrivere il codice non ottimale di proposito (senza motivi schiaccianti). I proprietari dei prodotti non dovrebbero fare confusione nei dettagli di sviluppo. –

In particolare per quanto riguarda il lettore mp3, probabilmente non si sta comparando con simili. Il tuo vecchio lettore mp3 486 ha fatto poco, ma riproduce l'mp3, Media Player trasporta un intero carico di cruft facendo effetti fantasiosi, un'interfaccia aerodinamica e tutto il resto. Per non parlare probabilmente di telefonare a casa e in una dozzina di altri posti del pianeta per far sapere a Microsoft cosa stai elencando troppo :-)

In realtà penso che questo sia vero più genericamente, il tipo di esperienza di interfaccia utente che ci è venuta aspettarsi che oggi abbia un prezzo sia in termini di cpu che di memoria. Penso che questo sarà molto più significativo di qualsiasi overhead in più dalla strutturazione del codice (e anche i nostri compilatori sono molto più intelligenti di 10 anni fa quindi dubito addirittura che sia un fattore a livello di codice macchina)

fonte

2009-07-22 23:40:16 Cruachan

Questo è quello che stavo pensando. iTunes utilizza fino a 9x - 10 volte la CPU con il visualizzatore come fa senza. E questo è con i filtri (EQ, ecc.) Per migliorare il suono che probabilmente non veniva usato tanto nei 486 giorni. – Jarrod

I ho trovato il contrario per essere vero. Il codice più semplice da leggere e mantenere ha avuto, nella mia esperienza, la tendenza ad essere il più performante in assoluto. Sono le gigantesche palle di fango di difficile lettura che tendono ad avere colli di bottiglia nelle prestazioni in luoghi strani che sono quasi impossibili da rimuovere o refactoring, quindi vengono lasciati lì.

fonte

2009-07-22 23:40:23 Lee

++ Non potrei essere più d'accordo.http: //stackoverflow.com/questions/926266/performance-optimization-strategies-of-last-resort/927773#927773 –

Preferisco chiamarli hairballs, ma +1 – kenny

Il codice bello può essere un codice veloce. Il problema può essere molte cose:

I linguaggi di livello superiore riducono notevolmente i tempi di sviluppo ma possono costare tempo del processore.Per un gran numero di applicazioni, questo è un ottimo compromesso
I programmatori non sono così istruiti sugli algoritmi come erano una volta - questo potrebbe essere correlato ai linguaggi di alto livello, dato che le persone usano solo il loro linguaggio integrato sort() invece di scegliere l'ordinamento rapido sopra l'ordinamento di inserimento
Le applicazioni fanno molto di più ora. Sono abbastanza sicuro che Media Player ha più funzioni di una vecchia versione di WinAmp

Non direi che il codice veloce è morto. Per controesempi, guarda il codice del sistema operativo (viene in mente lo scheduler O (1) in Linux) e ovviamente il codice del gioco.

fonte

2009-07-22 23:44:52

Se sei un fan di winamp, ti potrebbe interessare leggere questo fantastico articolo sugli orari interessanti di Justin Frankel in AOL dopo che AOL ha acquistato WinAmp.

Il suo ultimo prodotto è Reaper.

L'ottimizzazione ha più senso quando la piattaforma è fissata per un lungo periodo e si può davvero imparare. Questo succede ancora nei giochi per console.

Avendo scritto un linguaggio serrato per i giochi, posso dirti che ci vuole tempo. Scrivi lo stesso codice più e più volte e modifica le strutture dei dati, cercando di ottenere un ottimo framerate.

Non c'è più tale pressione sulle app per PC. Il presupposto è che il lavoro extra inserito raramente ripagherà, che chiunque desideri veloce comprerà un computer più veloce.

fonte

2009-07-22 23:46:28 Nosredna

-1

Non conosco alcun caso corrente in cui un buon compilatore non produrrà codice veloce ed efficiente se fornito di codice sorgente pulito e ben scritto.

Ora, se si utilizza una forma di generatore di codice, dipenderebbe dalla "bontà" dell'output sorgente del generatore. Certamente in passato ho visto generatori di codice che hanno creato tonnellate e tonnellate di codice spazzatura per operazioni apparentemente semplici. Penso che i progettisti degli strumenti soffrissero della "malattia di tutto il lavello della cucina". Gli strumenti moderni dovrebbero essere più snelli, ma vale la pena di controllare lo strumento prima di affossare un sacco di soldi.

Ancora una volta, se si scrive il proprio codice, ogni compilatore di cui sono a conoscenza oggi prenderà un codice buono e pulito e creerà file eseguibili veloci e ottimizzati. (a meno che non si spenga l'ottimizzazione per scopi di debug o qualcosa del genere).

Cheers,

-R

fonte

2009-07-23 00:13:51 Huntrods

Compilatori sono grandiosi, ma questo non significa che possano produrre codice fulmineo da soli. Ci vuole ancora del lavoro per realizzare un'app che sia efficiente con i media (dsp audio, video, animazione). Molto lavoro. – Nosredna

Trovo che le buone prestazioni derivino dall'uso di buone strutture di dati, dalla scrittura di algoritmi efficienti e dal non fare più * lavoro * del necessario e dall'ottimizzazione del codice dopo aver identificato i colli di bottiglia che utilizzano i profiler. Non trovo che le buone prestazioni siano legate alla pulizia del codice. –

Un algoritmo di crappy sarà lento, non importa quanto sia "gee-cool" il compilatore e perfettamente mantenibile il codice. – Adrien

Nella mia esperienza con il software non accademico, il più grande assassino prestazioni è l'uso di molti livelli di astrazione, ognuno dei quali esige una penalizzazione delle prestazioni modeste, ma si combinano come l'interesse composto. Ognuno può essere considerato una "cosa carina" e il "modo consigliato di fare le cose", finché non si vede il prezzo da pagare per questo.

Lo si vede soprattutto nei progetti guidati dagli eventi, in cui cose dall'aspetto innocente come l'impostazione di una proprietà hanno un effetto a cascata in una rete di classi.

fonte

2009-07-23 17:36:47

È facile confondere il codice progettato in modo esagerato con codice chiaro. Il primo è spesso difficile da mantenere e può produrre strozzature enigmatiche. Ma il diagramma UML probabilmente sembra davvero pulito.

fonte

2010-05-23 10:52:36 sharkin

La chiarezza del codice uccide le prestazioni dell'applicazione?

risposta

Problemi correlati