La lunghezza del nome della variabile è importante per le prestazioni C#?

Question

Mi sono chiesto se usare nomi di variabili lunghe descrittivi in ​​WinForms C# è importante per le prestazioni? Sto facendo questa domanda poiché in AutoIt v3 (linguaggio interpretato) è stato sollevato il fatto che avere variabili con nomi brevi come aa invece di veryLongVariableName è molto più veloce (quando il programma è più grande di 5 di linea). Mi chiedo se è lo stesso in C#?

Answer 1

No, non è così. Il compilatore in realtà non salva i nomi delle variabili originali, puoi guardare il codice IL di qualsiasi assembly compilato con disassemblatore.

Answer 2

No, non penso che la variabile lunga abbia alcun impatto sulle prestazioni di esecuzione di un'applicazione .NET. AFAIK, il codice intermedio (in MSIL) in un assembly .NET viene convertito nel linguaggio macchina prima che venga eseguito. Questo sarebbe dove i nomi delle variabili sono sicuramente "buttati" (se non è già accaduto prima) e sostituiti da semplici indirizzi di memoria.

Answer 3

Non importa. Nonostante tu possa ottenere i nomi quando decompilando (vedi altri post per i dettagli) questi nomi non sono usati dall'istruzione IL Leggere o scrivere in variabili/campi. Le variabili e i campi sono identificati attraverso un diverso costrutto. Nel namespace reflection.emit questi sono rappresentati da LocalBuilder (per una variabile locale o FieldBuild per i campi) e per sottolineare ulteriormente il punto: non è nemmeno necessario che siano nominati esplicitamente.

Answer 4

È una differenza fondamentale tra un compilatore e un interprete. Un interprete esegue una ricerca del nome identificatore mentre interpreta il codice. Se la ricerca del nome avviene all'interno di un ciclo che viene eseguito più volte, può essere importante il tempo necessario per tale ricerca. I nomi più lunghi richiedono più tempo.

Il compilatore C# elimina i nomi degli identificatori in due fasi distinte. I nomi delle variabili locali vengono cancellati e sostituiti dagli offset del frame stack quando compila il codice sorgente in IL. Nomi di spazio e nomi sono ancora presenti nell'assieme. Il compilatore JIT cancella quelli, sostituendoli con offset di codice per metodi e offset di dati per i campi. La lunghezza dei nomi degli identificatori non importa qui, la ricerca avviene solo una volta.

Eliminare la spesa della ricerca del nome in un interprete non è difficile. Un interprete decente raffigura il codice sorgente, essenzialmente una fase di pre-compilazione per rendere l'interprete più efficiente. Un tale interprete non avrebbe un problema di rallentamento con nomi di identificatori lunghi.

Answer 5

No, una volta compilati i nomi delle variabili originali non vengono più utilizzati. La dimensione dei nomi delle variabili dovrebbe avere un impatto molto piccolo sul tempo di compilazione, ma non sul tempo di esecuzione.

I linguaggi interpretati sono influenzati un po 'da nomi di variabili lunghe. I nomi lunghi sono più da leggere, memorizzare e cercare ogni volta che vengono eseguiti, ma l'effetto dovrebbe essere molto piccolo. La latenza in lettura/scrittura su un disco o persino sullo schermo dovrebbe superare di gran lunga il ritardo causato da nomi di variabili più lunghi.

Se il problema è il tempo di esecuzione, allora algoritmi più efficienti di esecuzione forniranno quasi certamente rendimenti molto maggiori rispetto alla riduzione dei nomi delle variabili. Se la pressione della memoria è il problema, gli algoritmi efficienti per la memoria riporteranno probabilmente molto più della semplice riduzione dei nomi delle variabili. Se la soluzione è algoritmicamente più stretta possibile, è l'ora di una nuova lingua.

Ci sono pochi assoluti nella programmazione, ma sono fiducioso nel dire che accorciare i nomi delle variabili nel codice sorgente per motivi di prestazioni è ASSOLUTAMENTE la decisione sbagliata OGNI volta.

Answer 6

Penso che la domanda sulla lunghezza del nome sia effettiva solo per i progetti Script# (in caso di traduzione di C# in JavaScript).