Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Per ridurre i costi di compilazione e editor, F# 11 condivide le librerie importate ed evita l'analisi ripetuta. Misurare il carico di lavoro interessato anziché presupporre un miglioramento della memoria o della velocità a livello di rilascio.
Condivisione della libreria binaria importata
FSharp.Compiler.Service può condividere grafici di libreria importati idonei tra progetti che usano le stesse dipendenze binarie.
FSharpChecker.Create espone shareImportedAssemblies, abilitato per impostazione predefinita. In questo modo si evita di conservare un grafo indipendente completo importato per ogni progetto.
La condivisione richiede la corrispondenza delle dipendenze risolte e le impostazioni di importazione. Project riferimenti, provider di tipi, assembly multimodulo e chiusura ambigue delle dipendenze vengono esclusi. Le importazioni del framework erano già condivise.
La pull request di implementazione ha misurato la memoria trattenuta dopo aver controllato e mantenuto in memoria tutti i progetti. Il carico di lavoro ReSharper.FSharp di dieci progetti ha usato 1.547,2 MB senza questa condivisione e 1.002,2 MB con esso. Il carico di lavoro della soluzione del compilatore è cambiato solo dello 0,1%. Si tratta di esperimenti specifici della modifica, non di risparmi universali derivanti dall'aggiornamento. La sovrapposizione in riferimenti binari di grandi dimensioni spiega gran parte della differenza.
Metadati conservati rispetto alle allocazioni temporanee
F# 11 riduce i metadati conservati tramite la creazione differita, tabelle più piccole e il riutilizzo. Separatamente, la lettura dei metadati e la specializzazione inline allocano meno dati temporanei. L'heap trattenuto, il volume di allocazione e la memoria del processo sono metriche diverse; non aggiungere risultati da questi esperimenti sovrapposti.
Analisi e navigazione dell'editor
I miglioramenti seguenti si applicano a livelli diversi:
| Componente | Lavoro evitato o delimitato |
|---|---|
| diagnostica di Visual Studio | Riutilizza la diagnostica dei documenti invariati con versioni di testo e progetto, percorsi e opzioni considerate. Questo riguarda l'analisi ripetuta in stato di inattività, non il riutilizzo arbitrario di risultati obsoleti. |
| Visual Studio Trova tutti i riferimenti e Rinomina | Limita i type check simultanei anziché avviarne uno per ogni documento contemporaneamente, mantenendo l'annullamento. |
| Ricerca di riferimenti ai simboli esterni | Ignora i progetti che non fanno riferimento all'assembly binario del simbolo. |
| Analisi incrementale FCS | Sincronizza lo stato del generatore in modo che le richieste sovrapposte non costruiscano catene di analisi duplicate per la stessa modifica. |
La correzione Peek evita un deadlock di navigazione dei metadati. Usare Go To Definition per le firme di metadati generate; Peek si arresta ai documenti esistenti. Questi miglioramenti richiedono componenti di editor/FCS aggiornati, non solo il pacchetto Core di un'applicazione.
Concorrenza delle attività di compilazione e build
La compilazione parallela usa per impostazione predefinita l'elaborazione indipendente dei file e delle fasi del compilatore in F# 11. L'ordine sorgente rimane parte del linguaggio; il parallelismo non consente le dipendenze forward.
Le attività di compilazione usano anche l'ambiente specifico per ogni attività e le strutture di percorso di MSBuild anziché modificare lo stato globale del processo. La memorizzazione nella cache dell'overload riduce la risoluzione ripetuta e la compilazione del pattern con guardia evita la duplicazione esplosiva in alcune combinazioni di disgiunzione/guardia.
Confronta la metrica di cui hai bisogno
- Per latenza di compilazione, confrontare compilazioni complete equivalenti con ottimizzazione identica, output deterministico, riferimento e impostazioni della cache. Usare
--parallelcompilation-per un confronto controllato. - Per la memoria dell'analisi retained, mantenere attivi gli stessi progetti e distinguere la memoria gestita attiva dal volume di allocazione e dalla memoria del processo.
- Per la velocità di risposta, riprodurre l'azione dell'editor o il carico di lavoro inattivo. L'output di un programma console non misura il lavoro di un editor.
Vedere anche
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
