PowerShell两种XML列表构建方式首次执行性能异常问询

这是个非常典型的网络文件系统缓存+PowerShell Provider初始化导致的性能差异问题，我之前处理过类似的共享目录访问场景，来给你拆解下背后的逻辑和解决办法：

核心原因 #

1. 网络文件系统缓存机制 #

你的测试路径是远程网络共享（\\Mac\Support\Px Tools\Dev 4.0），Windows系统对远程文件的访问依赖于文件系统缓存（Cache Manager）：

• 首次访问时，系统需要从远程服务器拉取目录结构、文件元数据（比如文件名、大小、修改时间），这个过程涉及网络IO，耗时自然高（你看到的2.5秒左右）。
• 后续重复访问时，这些元数据已经被缓存到本地内存中，不需要再发起远程请求，所以耗时骤降到1.5秒。
• 闲置数分钟后，系统会根据内存压力回收部分缓存，或者远程共享的缓存过期，再次访问时又需要重新拉取元数据，耗时回到初始状态。

2. PowerShell Provider初始化开销 #

PowerShell的Get-Item/Get-ChildItem依赖于FileSystem Provider来处理文件系统操作：

• 首次调用这些命令时，PowerShell需要加载FileSystem Provider的相关模块、初始化配置、建立与文件系统的连接，这部分有启动开销，会额外增加首次执行的耗时。
• 后续调用时，Provider已经处于初始化状态，这部分开销就消失了。

两种原因叠加，就导致了你看到的“首次执行耗时远高于后续”的现象——和你选择GIGC还是GCGC的顺序无关，本质上都是第一次触发了远程缓存加载和Provider初始化。

优化方案 #

针对这个问题，有几个非常实用的解决办法，按优先级排序：

1. 合并目录遍历操作，减少重复IO #

你的两种方式都做了两次目录遍历（一次找单个文件，一次找通配符文件），可以用-Include参数合并成一次遍历，直接获取所有目标文件：

Measure-Command {
    [Collections.ArrayList]$sourceDefinitions = @(
        Get-ChildItem $firmAssets -Include Definitions.xml, Definitions_*.xml -Recurse
    )
}

这样不管是首次还是后续执行，都只需要遍历一次目录，大幅减少IO操作次数，性能会比原来的两种方式都更好。

2. 预加载缓存与Provider #

如果必须保留原来的逻辑，或者需要确保脚本首次执行就有较好的性能，可以在脚本开头加一段“预缓存”代码，提前触发远程目录的缓存加载和Provider初始化：

# 预访问共享目录，触发缓存和Provider初始化
Get-ChildItem $firmAssets -ErrorAction SilentlyContinue | Out-Null

# 后续的实际操作
Measure-Command {
    [Collections.ArrayList]$sourceDefinitions = @(Get-Item "$firmAssets\Definitions.xml") + @(Get-ChildItem $firmAssets -Filter:Definitions_*.xml -Recurse)
}

这段代码会提前拉取共享目录的元数据到本地缓存，同时完成FileSystem Provider的初始化，后续真正的业务代码执行时就不会有首次开销了。

3. 调整PowerShell的执行策略（可选） #

如果你使用的是较旧的PowerShell版本（比如PS5.1及以下），可以尝试启用-UseTransaction参数（仅部分场景适用），或者调整PowerShell的ExecutionPolicy减少安全检查开销，但这个优化效果有限，优先级低于前两个方案。

内容的提问来源于stack exchange，提问作者Gordon