PowerShell 7 module lazy loading for low-traffic single script invocations

Question

Evaluating startup and execution cost for infrequent, single-script PowerShell invocations on Windows and cross-platform systems is a design concern for low-traffic workloads.

The goal is to minimize CPU, I/O and memory overhead per run. PowerShell 7 is documented to use module lazy loading, which differs from Windows PowerShell 5.1 behavior where referenced modules can be loaded earlier. Using non-interactive invocation is intended to avoid shell overhead, and local execution is generally preferred over remoting or background jobs for one-off runs.

An unresolved behavior is whether PowerShell 7's lazy loading can be relied upon for all third-party modules without triggering full loads. Some modules enforce initialization at parse time or via top-level side effects, which may defeat lazy loading assumptions.

Can module lazy loading be assumed safe for infrequent scripts that reference third-party modules? Which module patterns reliably avoid parse-time initialization in PowerShell 7? When does non-interactive script execution still incur module load cost?

Tasadduq Burney · Answer

AnswerConfirmed fact: PowerShell 7 defers loading a module until the first time any of its exported cmdlets or functions is invoked. This behavior is the same for interactive and non‑interactive runs.Likely explanation: Lazy loading adds negligible overhead only when the module’s import code (the module body or any .psd1 Import/Export block) contains no side‑effects such as assembly loads, type registrations, or global variable initializations. If a module follows that pattern, referencing it in a low‑traffic script will not cause a costly load until the function is actually needed.Steps to verify safety for a given third‑party moduleCheck the module’s .psd1 file: ensure there are no Import or Export script blocks that execute code (e.g., #<# ... #> or @ { ... } blocks).Inspect the .psm1 source: confirm that all executable statements are inside function definitions; there should be no top‑level code outside functions.Run a minimal test invocation with pwsh -NoProfile -NonInteractive -Command "& { Import-Module ;  }" and measure elapsed time (e.g., with Measure-Command). A sub‑millisecond delay indicates the module was not loaded until the function call.If the test shows noticeable latency, repeat the test after removing the function call; any remaining cost points to import‑time side effects.When non‑interactive execution still incurs loadEven with lazy loading, a non‑interactive script will load a module when:The script references any cmdlet/function from that module (the first reference triggers the load).An explicit Import-Module call is used.The module is required for parsing (e.g., a type from the module is used in a parameter attribute or a [typename] cast).The host loads core modules or profile‑independent dependencies unrelated to the lazy‑loaded module.Please confirm whether the module’s .psd1 contains any Import/Export script block that executes code on import; this detail determines whether the lazy‑loading assumption holds.

PowerShell 7 module lazy loading for low-traffic single script invocations

1 answer

Answer

Steps to verify safety for a given third‑party module

When non‑interactive execution still incurs load

Your perspective belongs here.

1 question comment