pwsh tool calls cost 4.2-4.7s on Windows while node/powershell/python spawn in 0.4-0.6s (0.2.1-rc.3)

[Yebeimu]

TL;DR — On 0.2.1-rc.3 / Windows 10, a tool call that goes through the pwsh wrapper costs 4.2–4.7 s of wall time while a call that spawns another program directly costs 0.46–0.67 s. pwsh.exe starts in 0.2 s on its own, and powershell.exe 5.1 goes through the same sandboxed spawn path in 0.6 s. Seven causes are ruled out below; the wait sits inside process creation and only pwsh.exe pays it.

Environment — DSH desktop 0.2.1-rc.3 (built 2026-10-23), Windows 10.0.19045, PowerShell 7.5.8, workspace-write sandbox. A local plugin replaces PwshLocalExecutor.prototype.argv with a direct split when the command is only "absolute path + arguments"; everything else keeps the stock pwsh -NoLogo -NoProfile -NonInteractive -Command "<cmd>". Numbers below are tool/call → tool/result from the session log.

The split

command	route	wall
exit	through pwsh	4,239 ms
Get-ChildItem, Get-Content, $var = … (5 calls)	through pwsh	4,246–4,691 ms
node.exe -e "…"	direct	424 ms
powershell.exe -NoProfile -Command "…"	direct	596 ms
python.exe <script> (7 calls)	direct	464–667 ms

Where the 4.2 s sits. A command whose only job is to print a timestamp printed 15:43:42.237. The tool call started at 15:43:37.986 and its result landed at 15:43:42.302. So 4,251 ms elapsed before the script ran its first statement, and 65 ms after its last one. It is not the command, not the output, and not the teardown.

Ruled out

candidate	measurement
pwsh startup itself	pwsh -NoProfile -Command exit outside DSH: 202 ms median
profile / module autoload	-NoProfile saves 8 ms (190 vs 198)
the UTF-8 -Command preamble	adding it to the command costs 20–150 ms
piped stdio	194–207 ms inherited vs 353–386 ms piped
the restricted token	powershell.exe 5.1 runs under the same Low-integrity token in 596 ms
teardown / grace	65 ms from the last statement to the result
the hook	read costs 84 ms end to end, the hook script 40–73 ms

The token is confirmed Low: whoami /groups reports Mandatory Label\Low Mandatory Level, and CIM is unavailable inside it, matching the documented Authenticated-Users removal.

Still unexplained — Inside an already-confined pwsh, spawning another pwsh takes 194–207 ms. Letting DSH spawn pwsh costs 4,239 ms. A minidump taken during the wait on 0.2.1-rc.2 had RIP at ZwCreateUserProcess+0x14, called from CreateProcessInternalW: the thread is waiting inside process creation, not computing.

So the question is what makes process creation take 4 s for pwsh.exe specifically, on a spawn path that builds the same restricted token and Job for node.exe and powershell.exe in 0.4–0.6 s. Has anyone instrumented launchWindowsJob, or is there a supported way to see where the per-spawn token and Job setup spends its time?

[Yebeimu]

Update — root cause found, plus a correction to what the 240–255 ms figure measured.

The 240–255 ms in my first reply was one PreToolUse hook. Hook commands on this machine are D:\Node\node.exe <script>, i.e. "absolute path + arguments", so skipping the pwsh wrapper gets them to 40–80 ms. That number never measured pwsh.exe itself. Spawning pwsh.exe directly, with no wrapper at all, still costs 4,493 ms.

The variable turns out to be the directory:

pwsh location	spawned directly from DSH	pwsh's own "process created → first statement"
C:\Program Files\PowerShell\7\pwsh.exe	4,493 ms	2,011 ms
copy under %LOCALAPPDATA%\Programs\pwsh7	907 ms	522 ms

Same binary, same command, same restriction level. Spawning it from Python costs 200–300 ms from either location, so it is the DSH spawn path plus that directory. The tree is 292 MB across 934 files (781 DLLs). The plausible mechanism is the extra restricting-SID pass over C:\Program Files' DACL on every file access, which dotnet.exe — a handful of DLLs, 418 ms — never accumulates. I could not verify that; there is no file-level trace yet.

Moving the tree to %LOCALAPPDATA%\Programs\pwsh7 and pointing the executor's argv[0] at the copy takes pwsh-backed calls from a 4,576 ms median to 920 ms (three calls: 920, 778, 933).

So there are two separate costs, and they need separate fixes: the shell wrapper (fixed by not using it when the command is already an argv) and the binary's location (fixed by moving it out of Program Files). Skipping the wrapper alone never showed the second one, because the hooks that got fast were node.exe, not pwsh.exe.

[Yebeimu]

Adding the evidence behind the location finding, and what the remaining 900 ms is made of.

The ACL difference between the two directories. Every file under C:\Program Files\PowerShell\7 carries five ACEs, two of them AppContainer package authorities:

NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Users:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
APPLICATION PACKAGE AUTHORITY\<locale-specific package>:(I)(RX)

The copy under %LOCALAPPDATA%\Programs carries four and no package ACE. My working theory is that a restricting-SID token pays an extra access check per object for those package ACEs, and 934 files across 781 DLLs accumulate ~1.5 s of it. The ACL difference is checked; the extra check per access is not — I have no syscall-level trace.

Where the 900 ms goes now. With the binary outside Program Files:

• pwsh's own startup: ~500 ms (the same binary launched from Python: ~200 ms; the gap is stdio pipes ~160 ms plus ~160 ms under the restricted token)
• DSH's spawn path: ~400 ms, split roughly 170 ms runner + 250 ms ACL sandbox

The sandbox share is measured directly: cmd.exe costs 439 ms inside the sandbox and 187 ms with danger-full-access, and cmd itself is 19 ms.

Still unexplained. The ~1.3 s kernel wait from the original report. The minidump landed on ZwCreateUserProcess+0x14 with the thread waiting, not computing, and that has not changed — moving the binary made the wait smaller without saying what it waits on. That needs kernel-level tooling we do not have; consider this one open.