Se lavori in aree veramente critiche per le prestazioni, non puoi rimandare l'efficienza come ripensamento. È una delle cose più importanti a cui pensare quando si progetta in anticipo in quei casi e in modi che riguardano la manutenibilità del risultato finale.
Non è possibile progettare e implementare un server su larga scala e iniziare a scrivere un codice semplice e ben documentato che utilizza solo funzioni di blocco per tutto con un blocco thread globale che blocca l'intero sistema per elaborare ogni singola richiesta client senza inserire alcuna pensato in qualsiasi stato condiviso, contesa sui thread e asincronicità. Tale è una ricetta per il disastro e la necessità di ridisegnare e riscrivere la maggior parte del codice ben documentato che hai scritto in modi che potrebbero portare alla base di codice più difficile da mantenere immaginabile, afflitta da condizioni di gara e deadlock a causa del tentativo per ottenere l'efficienza necessaria col senno di poi, invece di aver pensato in anticipo a progetti efficienti, semplici e funzionanti.
Un team di sviluppo del gioco a 8 mesi dalla produzione con un motore che va solo 2 frame al secondo sul proprio hardware più ape con 32 core mentre ha la tendenza a fermarsi per 15 secondi ogni volta che lo schermo è occupato è improbabile che ottenga immediatamente un prodotto utilizzabile solo riparare un piccolo hotspot localizzato. È probabile che il loro design sia FUBAR in modi che giustificano una rivisitazione epica del tavolo da disegno e modifiche del design che potrebbero precipitare in ogni angolo della base di codice.
Con John Carmack, ha parlato una volta di come deve essere eseguita una demo di tecnologia da un minimo di centinaia a migliaia di frame al secondo per integrarla nella produzione. Non è un'ossessione malsana per l'efficienza. Sa in anticipo che i giochi devono funzionare, nella loro interezza, a 30+ FPS affinché i clienti lo trovino accettabile. Di conseguenza un piccolo aspetto come un sistema di ombreggiatura sfumata non può essere eseguito a 30 FPS, altrimenti il gioco nel suo insieme non può essere abbastanza veloce da fornire il feedback in tempo reale richiesto. È inutilizzabile fino a quando non raggiunge l'efficienza richiesta. In tali settori critici per le prestazioni in cui esiste un requisito fondamentale per l'efficienza, una soluzione che non riesce a raggiungere una velocità adeguata non è in realtà migliore di una che non funziona affatto,. E non è possibile progettare un sistema di ombreggiatura sfumata efficiente che gira da centinaia a migliaia di fotogrammi al secondo, come richiesto per un motore di gioco in tempo reale, a meno che non si metta in primo piano una quantità predominante di pensiero sulla sua efficienza. In effetti, in questi casi, il 90 +% del lavoro è orientato all'efficienza poiché è banale trovare un sistema di ombreggiatura sfumata che funziona bene a 2 ore per fotogramma usando il tracciato del percorso, ma non puoi aspettarti di sintonizzarlo a funzionare a centinaia di frame al secondo senza un cambio di approccio totalmente diverso.
Quando l'efficienza è una parte fondamentale della progettazione di un'applicazione, non ci si può aspettare di raggiungere l'efficienza col senno di poi senza perdere notevolmente più tempo di quanto si è risparmiato ignorandola, dal momento che non ci si può aspettare di realizzare un progetto funzionante con il senno di poi. Nessuno dice: " Va bene rimandare a pensare al design fino a tardi. Basta documentare bene il codice e in seguito è possibile elaborare un design adeguato ". Ma nelle architetture critiche per le prestazioni, questo è ciò che stai effettivamente facendo se non metti molta cura e pensiero in progetti efficienti in anticipo.
Questo non significa che devi mettere a punto le tue implementazioni fin dall'inizio. Per i dettagli dell'implementazione, c'è molto spazio per passare a soluzioni più veloci dopo la misurazione, a condizione che il design non debba cambiare, e spesso questo è il modo più produttivo per procedere. Ma a livello di progettazione, ciò significa che devi riflettere a sufficienza su come il design e l'architettura saranno in relazione con l'efficienza sin dall'inizio.
La differenza chiave qui è il design. Non è facile apportare grandi cambiamenti ai progetti con il senno di poi poiché i progetti accumulano dipendenze e le dipendenze si romperanno se il progetto cambia. E se un progetto ha un requisito per essere ragionevolmente efficiente o, in alcuni casi, che la sua qualità è ampiamente misurata dalla sua efficienza, allora non dovresti aspettarti di essere in grado di ottenere un design adeguato come ripensamento. Con qualsiasi prodotto competitivo in cui l'efficienza è un aspetto enorme della qualità, che si tratti di sistemi operativi o compilatori o processori video o raytracer o motori di gioco o motori fisici, i pensieri sull'efficienza e la rappresentazione dei dati sono stati meticolosamente pensati fin dall'inizio. E in quei casi non è prematura l'ottimizzazione di mettere così tanto in primo piano l'efficienza. Stava ponendo questo pensiero esattamente nel momento più produttivo per farlo,