In realtà sono della mentalità molto opposta. Il modo più semplice per terminare la micro-tuning di una base di codice inutilmente per ore e molto lontano dalle operazioni di fine utente reali è quello di ossessionare i benchmark.
Si può finire con un rallentamento del test delle prestazioni per impiegare il doppio del tempo e poi sprecare ore con il team che lo ricerca e sintonizzarlo di nuovo quando, nel contesto dell'applicazione, la piccola funzionalità testata richiede solo lo 0,01% di il tempo, cercando di accelerare il backup di un inutile sforzo.
In realtà preferisco mantenere le prestazioni di un codebase piuttosto "organiche", come nel non tentare di consolidare il tutto con infiniti benchmark. Per lo meno, se vuoi aggiungere test delle prestazioni al tuo sistema, assicurati che siano di livello abbastanza alto e abbastanza vicini a quello che gli utenti effettivamente fanno con il software e frequentemente. In realtà non penso che un sistema di compilazione automatizzato non rispetti molto, omettendo i test delle prestazioni a patto che ci siano test di unità / integrazione per la correttezza, e io lavoro in aree critiche per le prestazioni.
La mia ex azienda ha effettuato tutti questi test delle prestazioni per cose finora rimosse dalle operazioni dell'utente, come solo il tempo necessario per chiamare una funzione in un'interfaccia di basso livello un milione di volte e ossessionare alcune fluttuazioni delle prestazioni per quelle aree sono controproducenti rispetto alla profilazione effettiva dell'applicazione rispetto a un caso d'uso del mondo reale. Arrivò persino al punto in cui le persone sprecavano innumerevoli ore di lavoro per indagare sui rallentamenti ai test delle prestazioni a basso livello, mentre le operazioni di alto livello dell'applicazione utente stavano diventando percepibilmente più veloci ... tuttavia gli sviluppatori erano ossessionati dal fatto di recuperare un valore fuori dalla proprietà ha avuto il 30% di tempo in più rispetto a quando sono stati avviati, anche se ciò ha avuto pochissime conseguenze sull'utente. Avrei preferito che fossero loro a profilare l'applicazione rispetto a questi micro-benchmark.
Gli hotspot tendono a spostarsi in casi rari in quanto le cose diventano più efficienti nei percorsi di esecuzione del caso comune, e in quella precedente esperienza, così tanti sviluppatori hanno sprecato tempo ed energie inutili cercando di ottimizzare i casi rari ossessionando questi giovani test sulle prestazioni. Altrettanto importante della misurazione, se non di più, è la completa comprensione di come il software viene comunemente utilizzato. Altrimenti potremmo misurare / benchmarking e mettere a punto le cose sbagliate e, nel peggiore dei casi, rendere effettivamente ciò che gli utenti effettivamente fanno più spesso meno efficiente nel processo.
Per me, la vera cartina di tornasole per capire se stai spendendo il tuo tempo di ottimizzazione in modo produttivo è se stai effettivamente misurando casi d'uso reali che gli utenti del software applicano comunemente e non prendendo pugnalate al buio (almeno misurando ). In genere, i più controproducenti in questo senso sono quelli più separati dal lato utente delle cose, non riuscendo a comprendere l'appeal e gli scenari di utilizzo del caso comune tra gli utenti del software.
Detto questo, penso che la "micro-ottimizzazione" sia più usata oltre la profilazione. Se, per "micro", ciò significa un'ottimizzazione senza alcun impatto sull'utente, anche i miglioramenti algoritmici sostanziali dovrebbero essere considerati "micro", ma non è così che viene tipicamente utilizzato. Spesso "micro" viene usato in modo intercambiabile con "controproducente", quando alcune delle ottimizzazioni più fruttuose e produttive non provengono da scoperte algoritmiche tanto quanto algoritmi pratici che applicano micro-ottimizzazioni efficaci (es: localizzazione migliorata di riferimento). Non mi interessa davvero se è sintonizzazione algoritmica o di basso livello di come i bit e i byte sono disposti in memoria o multithreading o SIMD. Tutto ciò che dovrebbe essere importante è se fa davvero la differenza, e non una funzione minuscola nel sistema chiamato di rado, ma all'utente reale del software.