In che modo le prestazioni sono influenzate da una direttiva using inutilizzata?


110

Visual Studio creerà automaticamente istruzioni using per te ogni volta che crei una nuova pagina o un nuovo progetto. Alcuni di questi non li userete mai.

Visual Studio ha l'utile funzionalità per "rimuovere gli utilizzi inutilizzati".

Mi chiedo se ci siano effetti negativi sulle prestazioni del programma se le istruzioni using a cui non si accede mai rimangono menzionate all'inizio del file.


L'ho cercato prima di chiedere e non è stato visualizzato.
KdgDev

6
FWIW, questo post ha una SEO migliore: è stato il primo risultato in Google per me. Dei 2 originali collegati, uno non è disponibile (rimosso) e l'altro è formulato in modo abbastanza diverso da aggiungere valore a questo post, anche se solo come reindirizzamento.
DaveD

@DaveD prima per te perché Google conosce le tue preferenze esatte e la cronologia delle ricerche. Nel computer del mio amico non era il primo.
ilias iliadis

Risposte:


133

Un utilizzo inutilizzato non ha alcun impatto sulle prestazioni di runtime dell'applicazione.

Può influire sulle prestazioni dell'IDE e sulla fase di compilazione complessiva. Il motivo è che crea uno spazio dei nomi aggiuntivo in cui deve avvenire la risoluzione dei nomi. Tuttavia, questi tendono ad essere minori e non dovrebbero avere un impatto evidente sulla tua esperienza IDE per la maggior parte degli scenari.

Può anche influire sulle prestazioni di valutazione delle espressioni nel debugger per gli stessi motivi.


38
Più utilizzi ci sono, più lento sarà Intellisense
Riegardt Steyn

14

No, è solo una cosa in fase di compilazione / stile di codifica. I binari .NET usano nomi completamente qualificati sotto il cofano.


3
Ciò significa che i nomi di classi e metodi più lunghi hanno un impatto piccolo ma effettivo (se incommensurabile) sui tempi di compilazione JIT?
Jared Updike

8

Nessun effetto sulla velocità di esecuzione, ma potrebbe esserci un leggero effetto sulla velocità di compilazione / intellisense poiché ci sono più potenziali spazi dei nomi per cercare la classe corretta. Non me ne preoccuperei troppo, ma puoi usare la voce di menu Organizza Usings per rimuovere e ordinare le istruzioni using.


8

Il seguente collegamento Una buona lettura sul perché rimuovere i riferimenti inutilizzati spiega come sia utile rimuovere i riferimenti inutilizzati dall'applicazione.

Di seguito alcuni estratti dal link:

  1. Rimuovendo tutti i riferimenti inutilizzati nell'applicazione, si impedisce al CLRcaricamento dei moduli di riferimento inutilizzati in fase di esecuzione. Ciò significa che ridurrai il tempo di avvio della tua applicazione, perché ci vuole tempo per caricare ogni modulo ed evita che il compilatore carichi i metadati che non verranno mai utilizzati. Potresti scoprire che, a seconda delle dimensioni di ciascuna libreria, il tempo di avvio è notevolmente ridotto. Questo non vuol dire che la tua applicazione sarà più veloce una volta caricata, ma può essere piuttosto utile sapere che il tempo di avvio potrebbe ridursi.

  2. Un altro vantaggio della rimozione di qualsiasi riferimento inutilizzato è che ridurrai il rischio di conflitti con gli spazi dei nomi. Ad esempio, se si dispone di entrambi System.Drawinge si fa System.Web.UI.WebControlsriferimento, è possibile che si ottengano conflitti quando si tenta di fare riferimento alla Imageclasse. Se nella tua classe sono presenti direttive using che corrispondono a questi riferimenti, il compilatore non può dire quale di quelle utilizzare. Se utilizzi regolarmente il completamento automatico durante lo sviluppo, la rimozione degli spazi dei nomi inutilizzati ridurrà il numero di valori di completamento automatico nell'editor di testo durante la digitazione.


5

No, ci sono diversi processi coinvolti durante la compilazione di un programma. Quando il compilatore inizia a cercare i riferimenti (classi, metodi) utilizzerà solo quelli utilizzati nel codice. La direttiva using dice solo al compilatore dove cercare. Molte istruzioni using inutilizzate potrebbero avere un problema di prestazioni, ma solo in fase di compilazione. In fase di esecuzione, tutto il codice esterno è correttamente collegato o incluso come parte del binario.


5

Il codice che non viene eseguito non influisce sulle prestazioni di un programma.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.