Ho un motore e se voglio usare il sistema 3d devo sempre passare un puntatore a qualsiasi renderer mesh. Se dovessi rendere statico il sistema 3d, potrei semplicemente usarli. Ma il sistema 3d è grande con un sacco di cose e risorse. So che i campi statici restano in memoria fino alla fine, ma il sistema grafico viene sempre utilizzato. Quindi è male per le prestazioni dichiarare il sistema 3d come un campo statico nel core del motore?
Per quanto riguarda le prestazioni, non ci sarà una grande differenza. Tuttavia:
Preferisci interfacce esplicite che rendano evidenti le loro dipendenze. Quindi passa i tuoi oggetti come argomenti, anche quando sono stati allocati con static di durata di archiviazione.
Evita static oggetti perché l'inizializzazione e la distruzione di questi oggetti è molto complessa. Ad esempio, l'ordine di inizializzazione potrebbe essere indefinito. Per questo motivo mi sono occupato di molti bug difficili da riprodurre. Potrebbe ancora avere senso avere un static unique_ptr<SomeComplexObject> che si assegna durante l'inizializzazione dell'applicazione (ad es. In main() ), ma ha un valore trascurabile rispetto al passaggio di un riferimento intorno.
In sezioni estremamente critiche per le prestazioni, è possibile evitare di eseguire il riferimento indiretto da un riferimento o da una variabile globale che è un puntatore. Questo puntatore indiretto potrebbe anche impedire alcune ottimizzazioni. Tuttavia, queste differenze riguarderanno probabilmente solo gli effetti della cache o le differenze di prestazioni a ciclo singolo, quindi non pensare di compromettere la tua progettazione per le prestazioni senza profilare i dati per sostenere questa decisione.
Pensandoci meglio, mi aspetto che la differenza più grande risieda nel passare da un argomento in più a molte funzioni. Ciò potrebbe causare una convenzione di chiamata per scrivere argomenti nello stack anziché utilizzare solo registri. Ma se vuoi evitarlo, scrivere codice inlineabile sarà più utile che scegliere un design problematico.
Nella maggior parte dei casi, la scelta di un design sensibile è più importante che andare dopo micro-ottimizzazioni come questa. Le maggiori prestazioni vinte solitamente derivano dal evitare di lavorare interamente, e non dal fare più velocemente lo stesso lavoro. Un design pulito renderà più facile per te individuare opportunità per evitare il lavoro non necessario, mentre tali cambiamenti potrebbero essere molto difficili in un codice altamente "ottimizzato". Rendere esplicite le dipendenze tende a far parte di un design pulito.