Promuovere un periodo di tempo in cui tutti possono provare qualche idea per rendere il software più veloce?

A volte i trucchi per le prestazioni del software si trovano da una ricerca metodologica e approfondita. A volte richiede un pensiero divergente e coraggio per provare idee folli. A volte un'idea è solo l'inizio che deve essere seguita con molto duro lavoro.

Come promuovere un periodo di tempo in cui tutti possono provare idee diverse per migliorare le prestazioni del software su cui stiamo lavorando? Tutti nel team hanno almeno diversi mesi di esperienza con il software e sono molto bravi a farlo.

Sei d'accordo sul fatto che un pensiero divergente aiuterà a trovare modi per migliorare le prestazioni del software? Perché? Perchè no?

Quali tecniche ci consentiranno di provare rapidamente un'idea di ottimizzazione? È necessaria una velocità di codifica elevata per ottenere buoni risultati dalla prova?

Infine, quanto "tempo" dovrebbe essere assegnato per garantire buoni risultati senza creare la possibilità di rallentare?

È necessaria la sperimentazione per dimostrare che esiste "un modo più veloce di fare qualcosa"? (Aggiunto il 07/06/2011)

Relazionato:

• Quali sono le tue strategie per migliorare il livello della tua squadra in modo intelligente?
• Quando gli hack del codice diventano cattivi?

( Solo a scopo di taglia -2011/06/07, la dimensione del team è di 2-4 sviluppatori, nessun QA dedicato. Tutto il codice, unit test e test delle prestazioni eseguiti dagli sviluppatori. A causa della natura del progetto, il risultato del profiler è utile per mostrare tempo di esecuzione proporzionale anche se non rivela un singolo collo di bottiglia.)

La tua scommessa migliore è identificare gli hotspot con un profiler e, come squadra, discutere su come risolvere gli hotspot.

Devi essere in grado di misurare e documentare il miglioramento (quindi non è solo un'ipotesi selvaggia) e farlo in gruppo assicura che le persone sappiano cosa viene risolto e come.

Avere programmatori hackerare selvaggiamente la base di codice mentre provano idee significa che non hai alcun controllo su ciò che sta succedendo e se funziona.

I programmatori tendono ad essere intelligenti e creativi (poiché questi sono i prerequisiti per essere bravi a programmare), quindi è sempre bene lasciarli provare una vasta gamma di idee quando provano a risolvere i problemi. Vi sono tuttavia due cose che sono importanti da ricordare quando si tenta di migliorare le prestazioni (suppongo che con "prestazioni" intendiate ridurre la velocità di esecuzione):

• Le ottimizzazioni algoritmiche tendono a funzionare molto meglio di ogni altra cosa. A titolo di esempio banale, qualunque cosa facciate all'implementazione di bubblesort, con numeri sufficienti un'implementazione estremamente lenta di quicksort sarà infine più veloce.
• Fare qualsiasi cosa legata alle prestazioni è completamente privo di senso a meno che non si misuri (profilo) e si basi qualsiasi cosa si faccia sui risultati.

Il mio punto principale è che è importante assicurarsi di essere sulla stessa pagina con tutti gli utenti per quanto riguarda queste cose prima di iniziare un periodo di sperimentazione selvaggia . È sempre un peccato scoprire in seguito che i tuoi colleghi meno esperti stavano provando cose che non avrebbero mai potuto funzionare (e avresti potuto dirglielo in anticipo).

Purtroppo, non posso parlare per esperienza. Ma ho sentito che Atlassian ha un solo giorno in cui i dipendenti sono stati autorizzati a fare le proprie cose, qualunque cosa volessero, e presentare le loro idee in una sorta di atmosfera di festa. A quanto pare è andato bene per loro. Ma dovrei essere d'accordo con Andersen e dire che quando si tratta di performance, le idee creative e pronte all'uso sono meno importanti della profilazione dei processi che richiedono più tempo. Forse, una volta che hai profilato il tuo sistema, potresti dare a tutti un giorno di elaborare idee su come aiutare ad accelerare sezioni importanti del processo. Dopo che presentano le loro idee, puoi scegliere quali provare.

Una pratica di successo che abbiamo fatto su alcune delle mie squadre precedenti era il concetto di Deep Dives. Alcune persone si riuniscono in una sala conferenze, determinano alcuni scenari utente e iniziano semplicemente a sfogliare il codice o guardare i registri del profiler. In alcuni casi, i dati hanno mostrato chiaramente colli di bottiglia che ci hanno permesso di convincere gli scettici che c'erano davvero problemi di perf nel loro codice! Per avere successo, ci sono stati alcuni principi chiave che abbiamo seguito:

1. Cerca di concentrarti su scenari critici o percorsi di codice in cui si sospetta colli di bottiglia. Non perdere tempo nell'ottimizzare cose che non hanno bisogno di essere ottimizzate (se non è rotto ...)
2. Mantieni il gruppo piccolo e focalizzato sulle persone che conoscono meglio il codice. Non dimenticare di includere il tester e il gestore del programma della funzione: hanno informazioni chiave e possono trarre vantaggio dalla partecipazione o dalla raccolta di informazioni su come testare meglio.
3. Inizia la sessione facendo in modo che il proprietario dell'area fornisca un diagramma di livello di blocco architettonico di alto livello e una panoramica dell'area. Quali sono i componenti chiave e descrivono brevemente cosa fanno. Rimarrai sorpreso da quante volte lo schema a blocchi non rifletteva la realtà una volta scavato nel codice. (Citazione attuale: "Non sapevo che avessimo ancora usato quel componente. Pensavo che ce ne saremmo liberati anni fa!")
4. Aspettati di trovare bug funzionali e problemi di perf. È una buona cosa. Inoltre, aspettati che, a volte, non troverai nulla di significativo. Anche questa può essere una buona cosa.
5. Aspettatevi di avere diverse sessioni lunghe. Questi sono incontri di lavoro. Mettiti comodo e lavoraci. Fai molto di più quando tutti puoi collaborare per lunghi tratti.
6. Prendi appunti, buoni appunti. Se si utilizza un database di tracciamento dei difetti, prendere in considerazione l'apertura immediata dei problemi per tenere traccia, anche se hanno priorità bassa.

Evitare che l'intero team partecipi a una "Performance Push". Questi di solito non hanno i risultati che la direzione si aspetta per i motivi che Thorbjørn Ravn Andersen ha menzionato in un'altra risposta. Otterrai grandi guadagni in alcune aree, regressioni in altre aree in cui le persone non sono familiari, ed è difficile prevedere / tracciare quanti guadagni dovresti dire "hai finito". È una conversazione stimolante da avere con il management.

Il motivo per cui potresti dover migliorare la velocità del tuo software è se qualcosa è notevolmente lento. In caso contrario, l'ottimizzazione è una perdita di tempo. Ma se qualcosa è lento, allora fai il lavoro.

... E per svolgere l'attività, ci sono due passaggi in questo ordine:

1. Verifica se la funzione che sta eseguendo l'attività è scritta in modo efficiente. Ha un algoritmo buono o scarso? Accede a un database in modo efficiente. È in loop 100 volte quando una volta può fare? Spesso, la semplice ispezione del codice può trovare l'unico ostacolo e non solo risolverlo, ma renderti un programmatore migliore allo stesso tempo.

2. Non spendere più di un'ora circa al numero 1. Se non riesci a trovare il problema in un'ora, usa un profiler per trovare il punto in questione. Una volta che conosci il punto problematico, puoi tornare al numero 1 e farlo di nuovo, andando verso il basso per trovare il modo migliore per migliorare il codice che hai identificato.

In generale (**) non si ottengono prestazioni migliori mediante la sperimentazione.

Lo capisci

• Saper iniziare con un design semplice ed efficiente. Se sbagli questa parte, la sperimentazione non farà molta differenza. Ad esempio, sapere come usare un generatore di codice è un approccio progettuale vincente.

• Saper ottimizzare il software individuando le attività a) costose su base percentuale eb) sostituibili con qualcosa di meglio. Tutti sanno che dovresti "usare un profiler", ma non è abbastanza.

Controlla questa risposta all'altra tua domanda.

** Le eccezioni potrebbero essere il codice strettamente dipendente dall'hardware, come il rendering della grafica, la pipeline del processore o il comportamento CUDA o la sperimentazione di protocolli di rete o DB, in cui è sufficiente acquisire familiarità con il modo migliore per utilizzarlo.

AGGIUNTO: C'è qualcosa che molti programmatori di grandi sistemi trovano sorprendente. È che in grandi programmi perfettamente ben costruiti, ci possono essere problemi di prestazioni grandi e invisibili , e i profiler non riescono a trovarli perché non sono localizzati nelle routine. Fanno parte della struttura generale del programma, anche se il programma può essere eseguito nel migliore dei modi.

Giusto per fare un esempio concreto, ecco un programma con codice sorgente (in C ++) che fa un lavoro. È distillato da un vero programma C su cui ho lavorato.

Fa quello che doveva fare, ma quale frazione del suo tempo non è davvero necessaria? Quanto potrebbe essere accelerato?

Bene, nella prima versione del programma, qualcosa di perfettamente ragionevole e non locale (invisibile a un profiler) impiegava il 33,3% delle volte. Quando è stato sostituito, quel tempo è stato salvato e quella era la seconda versione del programma.

Nella seconda versione del programma, qualcos'altro (invisibile a qualsiasi profiler) che poteva essere rimosso richiedeva il 16,7% delle volte. La sua rimozione ha portato alla versione 3.

Nella versione 3, il 13% è stato rimosso. Di ciò che era rimasto, il 66% è stato rimosso. Di ciò che è rimasto dopo, il 61% è stato rimosso!

Infine, da ciò che è rimasto dopo, il 98% è stato rimosso!

Qual è il quadro generale? Su ogni 1000 cicli spesi dal programma originale, quanti sono stati rimossi? 998!

Ogni programma è diverso, ma ogni programma di grandi dimensioni, nella mia esperienza, ha una serie di problemi di tempo che i profiler non troveranno, che il campionamento manuale lo farà e che, se i programmatori stanno davvero cercando la massima prestazione, possono essere rimossi per grandi accelerazioni.