Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Pour réduire les coûts de génération et d’éditeur, F# 11 partage les bibliothèques importées et évite l’analyse répétée. Mesurez la charge de travail affectée plutôt que d’assumer une vitesse à l’échelle de la mise en production ou une amélioration de la mémoire.
Partage de bibliothèque binaire importé
FSharp.Compiler.Service peut partager des graphiques de bibliothèque importés éligibles entre les projets qui utilisent les mêmes dépendances binaires.
FSharpChecker.Create
shareImportedAssembliesexpose , activé par défaut. Cela évite de conserver un graphique importé indépendant complet pour chaque projet.
Le partage nécessite la correspondance des dépendances résolues et des paramètres d’importation. Project références, fournisseurs de types, assemblys multimodèles et fermetures de dépendance ambiguës sont exclues. Les importations de framework ont déjà été partagées.
La PR d’implémentation mesurait la mémoire conservée après vérification et conservation de tous les projets. Sa charge de travail ReSharper.FSharp de dix projets a utilisé 1 547,2 Mo sans ce partage et 1 002,2 Mo avec lui. Sa charge de travail du compilateur-solution a été modifiée uniquement par 0.1%. Il s’agit d’expériences spécifiques aux modifications, et non d’économies de mise à niveau universelles. Le chevauchement dans les références binaires volumineuses explique une grande partie de la différence.
Métadonnées conservées par rapport aux allocations temporaires
F# 11 réduit les métadonnées conservées via la création différée, les tables plus petites et la réutilisation. Séparément, la lecture des métadonnées et la spécialisation inline allouent moins de données temporaires. Le tas conservé, le volume d’allocation et la mémoire du processus sont des métriques différentes ; n’ajoutez pas de résultats à partir de ces expériences qui se chevauchent.
Analyse de l’éditeur et navigation
Les améliorations suivantes s’appliquent à différentes couches :
| Component | Travail évité ou limité |
|---|---|
| diagnostics Visual Studio | Réutilise les diagnostics de document inchangés avec des versions de texte et de projet, des chemins et des options pris en compte. Cela cible l’analyse répétée en veille, et non la réutilisation arbitraire des résultats obsolètes. |
| Visual Studio rechercher toutes les références et renommer | Limite les vérifications de type simultanées plutôt que de lancer une pour chaque document à la fois, tout en conservant l’annulation. |
| Recherche de références de symboles externes | Ignore les projets qui ne font pas référence à l’assemblage binaire du symbole. |
| Analyse incrémentielle FCS | Synchronise l’état du générateur afin que les requêtes qui se chevauchent ne construisent pas de chaînes d’analyse en double pour la même modification. |
Le correctif d’aperçu évite un blocage de navigation par métadonnées. Utilisez Go To Definition pour les signatures de métadonnées générées ; Peek s’arrête aux documents existants. Ces améliorations nécessitent des composants de l’éditeur/FCS mis à jour, et non pas simplement le package Core d’une application.
Concurrence de compilation et de tâche de génération
La compilation parallèle utilise par défaut le traitement indépendant des fichiers et des phases du compilateur en F# 11. L’ordre source fait partie de la langue ; le parallélisme ne légalise pas les dépendances vers l’avant.
Les tâches de génération utilisent également l’environnement par tâche de MSBuild et les installations de chemin d’accès au lieu de modifier l’état global du processus. La mise en cache de surcharge réduit la résolution répétée et la compilation de modèles gardés évite la duplication explosive dans certaines combinaisons disjonction/garde.
Comparez la métrique souhaitée
- Pour une latence de build, comparez les builds complètes équivalentes avec des paramètres identiques d’optimisation, de sortie déterministe, de référence et de cache. Utiliser
--parallelcompilation-pour une comparaison contrôlée. - Pour conserver la mémoire conservée pour l’analyse, gardez les mêmes projets actifs et distinguez la mémoire managée active du volume d’allocation et de la mémoire du processus.
- Pour plus de réactivité, reproduisez l’action dans l’éditeur ou la charge de travail au repos. La sortie d’un programme console ne mesure pas le travail d’un éditeur.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
