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

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

Devi essere in grado di misurare e documentare il miglioramento (quindi non si tratta solo di ipotesi selvagge) e farlo in gruppo assicura che le persone sappiano cosa è stato corretto e come.

Avere programmatori che si attaccano selvaggiamente al codice base provano le idee per dire che non hai il controllo di ciò che sta succedendo e se funziona.

I programmatori tendono ad essere intelligenti e creativi (dal momento che questi sono prerequisiti per essere bravi a programmare) quindi è sempre bene lasciarli provare una vasta gamma di idee quando si cerca di risolvere i problemi. Ci sono tuttavia due cose che è importante ricordare quando si tenta di migliorare le prestazioni (suppongo che con "prestazioni" intendi ridurre la velocità di esecuzione):

• Le ottimizzazioni algoritmiche tendono a funzionare molto meglio di qualsiasi altra cosa. Come esempio banale, qualunque cosa tu faccia per la tua implementazione di bubblesort, con numeri sufficienti un'implementazione estremamente lenta di quicksort alla fine sarà più veloce.
• Fare qualsiasi cosa legata alle prestazioni è completamente privo di senso a meno che non misuri (profilo) e basi tutto ciò che fai sui risultati.

Il mio punto principale è che è importante assicurarsi di essere sulla stessa pagina con tutti 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 dove i dipendenti potevano fare le loro cose, qualunque cosa volevano e presentavano le loro idee in una sorta di atmosfera di festa. Apparentemente è risultato per loro apparentemente. Ma dovrei essere d'accordo con Andersen e dire che quando si tratta di prestazioni, le idee creative e pronte all'uso sono meno importanti, quindi definire quali processi richiedono più tempo. Forse una volta che avrai profilato il tuo sistema, potresti dare a tutti un giorno delle idee su come contribuire ad accelerare importanti sezioni del processo. Dopo aver presentato le loro idee, puoi scegliere quelle da provare.

Una pratica di successo che abbiamo fatto in alcuni dei miei team precedenti era il concetto di Deep Dives. Alcune persone si riuniscono in una sala conferenze, determinano alcuni scenari utente e iniziano semplicemente passando il codice o guardando i registri del profiler. In alcuni casi, i dati mostravano chiaramente i colli di bottiglia che ci permettevano di convincere gli scettici che c'erano davvero problemi con il loro codice! Per riuscirci, c'erano alcuni principi chiave che abbiamo seguito:

1. Cerca di concentrarti su scenari critici o percorsi di codice in cui si sospettano i colli di bottiglia. Non sprecare tempo nell'ottimizzare roba che non ha bisogno di essere ottimizzata (se non è rotta ...)
2. Mantieni il gruppo piccolo e concentrato sulle persone che conoscono meglio il codice. Non dimenticare di includere il tester e il gestore del programma della funzione - hanno approfondimenti chiave e possono trarre vantaggio da entrambi i partecipanti o raccogliere informazioni su come possono testare meglio.
3. Avvia la sessione facendo in modo che il proprietario dell'area fornisca un diagramma a livello di blocco architettonico di alto livello e una panoramica dell'area. Quali sono i componenti chiave e descrivi brevemente cosa fanno. Rimarrai sorpreso dal numero di volte in cui il diagramma a blocchi non riflette la realtà una volta scavato nel codice. (Citazione reale: "Non sapevo di aver ancora usato quel componente, pensavo che ci siamo liberati di quegli anni fa!")
4. Aspettatevi di trovare bug funzionali e problemi di perf. È una buona cosa. Inoltre, ti aspetti che, a volte, non troverai nulla di significativo. Anche questa può essere una buona cosa.
5. Aspettatevi di avere diverse lunghe sessioni. Questi sono incontri di lavoro. Mettiti comodo e lavora su di esso. Si ottiene molto di più quando tutti possono collaborare per estensioni prolungate.
6. prendi appunti, note positive. Se si utilizza un database di rilevamento dei difetti, prendere in considerazione l'apertura immediata dei problemi per tenere traccia, anche se hanno bassa priorità.

Evitare che l'intera squadra partecipi a una "Performance Push". Questi di solito non hanno i risultati che il management si aspetta per i motivi che Thorbjørn Ravn Andersen menzionato in un'altra risposta. Otterrai grandi guadagni in alcune aree, regressioni in altre aree dove le persone non hanno familiarità, ed è difficile prevedere / tracciare quanto guadagni dovresti dire "hai finito". È una conversazione impegnativa da avere con la gestione.

Il motivo per cui potrebbe essere necessario migliorare la velocità del software è se qualcosa in esso è notevolmente lento. Se questo non è il caso, quindi l'ottimizzazione è una perdita di tempo. Ma se qualcosa è lento, allora esegui il compito.

... E per fare il compito, ci sono due passaggi in questo ordine:

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

2. Non trascorrere più di un'ora sul numero 1. Se non trovi il problema entro un'ora, utilizza un profiler per trovare il punto in questione. Una volta che conosci il problema, puoi tornare al numero 1 e farlo di nuovo, tenendo premuto per trovare il modo migliore per migliorare il codice che hai identificato.

In generale (**) non ottieni prestazioni migliori con la sperimentazione.

L'hai capito

• Sapere come creare un design semplice ed efficiente per iniziare. Se si sbaglia questa parte, la sperimentazione non farà molta differenza. Ad esempio, sapere come capire quando utilizzare un generatore di codice è un approccio di progettazione vincente.

• Sapere come ottimizzare il software individuando le attività che sono a) costose in termini percentuali e b) sostituibili con qualcosa di meglio. Tutti sanno che dovresti "usare un profiler", ma non è sufficiente.

Controlla questa risposta alla tua altra domanda.

** Le eccezioni potrebbero essere un codice strettamente dipendente dall'hardware, come il rendering grafico, la pipeline del processore o il comportamento CUDA, o sperimentare con i protocolli di rete o DB, dove devi solo familiarizzare con il modo migliore per usarlo.

AGGIUNTO: C'è qualcosa che molti programmatori di sistemi di grandi dimensioni trovano sorprendenti. È che in grandi programmi perfettamente ben costruiti, ci possono essere problemi di prestazioni grandi, 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 fatto nello stile migliore.

Solo per dare 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 ciò che è stato destinato a fare, ma quale frazione del suo tempo non è veramente necessaria? Quanto potrebbe essere accelerato?

Beh, nella prima versione del programma, qualcosa di perfettamente ragionevole e non locale (invisibile a un profiler) stava prendendo il 33.3% delle volte. Quando è stato sostituito, quella volta è stata salvata, e quella era la seconda versione del programma.

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

Nella versione 3, il 13% è stato rimosso. Fuori da ciò che è rimasto, il 66% è stato rimosso. Da ciò che è rimasto dopo, il 61% è stato rimosso!

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

Quindi qual è il quadro generale? Su 1000 cicli trascorsi dal programma originale, quanti sono stati rimossi? 998!

Ogni programma è diverso, ma ogni grande programma, nella mia esperienza, ha una serie di problemi che i profiler non troveranno, che il campionamento manuale farà, e che, se i programmatori sono veramente andare per le massime prestazioni, può essere rimosso per grandi aumenti di velocità.