Partager via

Considérations relatives à la création de modules PowerShell

  • Article

Ce document contient des instructions relatives à la création d’un module pour des performances optimales.

Création du manifeste d’un module

Un manifeste de module qui n’utilise pas les recommandations suivantes peut avoir un impact notable sur les performances générales de PowerShell, même si le module n’est pas utilisé dans une session.

La découverte automatique des commandes analyse chaque module afin de déterminer les commandes qui sont exportées par ce module, et cette analyse peut être coûteuse. Les résultats de l’analyse des modules sont mis en cache pour chaque utilisateur, mais le cache n’est pas disponible lors de la première exécution, ce qui est typique avec les conteneurs. Si les commandes exportées peuvent être toutes déterminées à partir du manifeste pendant l’analyse des modules, vous éviterez l’analyse coûteuse du module.

Consignes

  • Dans le manifeste du module, n’utilisez pas de caractères génériques dans les entrées AliasesToExport, CmdletsToExport et FunctionsToExport.

  • Si le module n’exporte pas de commandes d’un type particulier, spécifiez-le explicitement dans le manifeste en indiquant @(). Une entrée manquante ou $null revient à spécifier le caractère générique *.

Les éléments suivants doivent être évités dans la mesure du possible :

@{
    FunctionsToExport = '*'

    # Also avoid omitting an entry, it's equivalent to using a wildcard
    # CmdletsToExport = '*'
    # AliasesToExport = '*'
}

Utilisez à la place :

@{
    FunctionsToExport = 'Format-Hex', 'Format-Octal'
    CmdletsToExport = @()  # Specify an empty array, not $null
    AliasesToExport = @()  # Also ensure all three entries are present
}

Éviter le CDXML

Lorsque vous décidez de la façon d’implémenter votre module, vous avez trois options principales :

  • Binaire (généralement C#)
  • Script (PowerShell)
  • CDXML (fichier XML avec wrapping CIM)

Si la vitesse de chargement de votre module est importante, sachez que le CDXML est beaucoup plus lent qu’un module binaire.

Un module binaire est le type de module qui se charge le plus rapidement, car il fait l’objet d’une compilation Ahead Of Time et ne peut utiliser NGen pour la compilation JIT qu’une seule fois par machine.

Un module de script est chargé généralement un peu plus lentement qu’un module binaire, car PowerShell doit analyser le script avant de le compiler et de l’exécuter.

Un module CDXML est généralement beaucoup plus lent qu’un module de script. En effet, il doit d’abord analyser un fichier XML, qui génère un script PowerShell relativement volumineux, lequel est ensuite analysé et compilé.