On about 25% of the laptops in our group, the following command run in a new powershell window is surprisingly slow -- 20 to 30 seconds for 10 empty jobs:

PS C:\temp> (measure-command { 1..10 | %{ start-job { $null } }; get-job | wait-job; get-job | remove-job } ).totalseconds
21.6354752
PS C:\temp>

Note that if you run the command a second time, it is up to 10x faster. But if you wait a minute or two and try again, or open a new window and try again, it is slow again. 100% repeatable for systems with the issue (about 75% of the laptops in our group do not have the issue, and I am guessing it is because they have more cores -- I have 4 cores, 16GB RAM, and Samsung EVO SSD.)

I have done a bunch of analysis here, and I am convinced the following happens... For starters, the parent powershell launches 10 children, one at a time, with maybe a half of a second between each launch. Then one or two of the children might start running, but most of them just sit there waiting for most of the 20'ish seconds. Then the remaining 8 or 9 powershells start running at the same intervals as they launched -- like a half second between each run (as if the overall delay time is fixed for each process). Then all processes complete together.

Note that the system is idle for 90% of the time, at 0% CPU, while we wait 20 seconds for the empty jobs to complete. This is the bug -- an idle system waiting for over 15 seconds doing nothing.

You can see this by changing "$false" above to "c:\xxx.exe" -- then in procmon or xperf, you can see the (failed) references to c:\xxx.exe very close to the end of the trace.

It is possible this is because I have 4 cores in my system:

PS C:\temp> (get-process -id 0).threads.count
4
PS C:\temp>

I am richardt@microsoft.com. I have tons of xperf and procmon traces, and have done a lot of initial digging into this -- it seems to be excess cleverness in the clr threadpool implementation that brings on pathologies in certain CPU configurations... Please reach out to me before closing this as not repro or not important -- we're now moving away from powershell jobs for all our testing infrastructure (to C#, since if we have to go out-of-box to get powershell to work, it's not worth the risk -- we run our tests in VSO). I hate to see folks be unable to use powershell for something as simple as launching background jobs -- this is 100% something folks should reliably be able to use powershell for! I hope we can fix this!!!

Below/attached is xperf/wpa trace showing the 10 children processes start up sequentially, and then hang idle for 15 seconds, and then eventually shut down (also somewhat sequentially).