4

This completes in 2.3 minutes on LOCALSERVER:

A: measure-command {$x = invoke-command {gci -recurse "C:\"}}

This completes in 38.4 minutes on LOCALSERVER:

B: measure-command {$x = invoke-command -comp LOCALSERVER {gci -recurse "C:\"}}

Why is B so much slower? Is it because the "output is being serialized to XML and then reconstituted into objects again", as explained here, with B but not A? Or is something else going on?

LOCALSERVER runs Windows 2008R2 with PS v3. In both cases $x.count is 98973.

I was wondering about changing an existing script to use PSRemoting for file searches on remote servers. I thought the searches might finish sooner with gci running on the remote target. In a handful of tests, the searches actually ran much longer with PSRemoting. I'm asking about the loopback scenario only because it seemed like the simplest case; I saw similar results with remote servers. So I'll stick with UNC path searches like this:

gci -recurse \\REMOTESERVER\C$\folder

...unless these results seem odd, and some adjustment to my remoting configuration or syntax might offer a big performance boost?

Community
  • 1
  • 1
noam
  • 1,914
  • 2
  • 20
  • 26
  • I've seen remote ps scripts take forever in a local IDE but when ran via powershell command line they complete in a fraction of the time... has to do with how threading is handled (using x86 or x64 IDE changes behavior I believe) – Brock Hensley Apr 18 '13 at 21:17
  • No IDE for these tests. I just typed `powershell` at a vanilla cmd prompt. – noam Apr 18 '13 at 21:19

3 Answers3

2

As you mentioned, the time required to invoke the command remotely must also take into account the time needed to deserialize any given object you return from your remote pipeline (in your case the whole tree of FileSystemInfo of the C drive). I would suggest to limit the number of objects you serialize and deserialize over the network and, while comparing performances of your servers, perhaps consider the time taken from within the machine you are running the code on:

Invoke-Command -comp LOCALSERVER { Measure-Command { gci -recurse "C:\" } }
Efran Cobisi
  • 6,138
  • 22
  • 22
  • Thanks, I'll experiment with filtering results on the remote side. – noam Apr 19 '13 at 19:59
  • You dropped my answer for this one? I'm not sure how this helps you more than mine does. No offense, Efran. – x0n Apr 20 '13 at 02:12
  • I was torn. Yours is the clearest and most direct answer, but Efran's got me filtering gci results on the remote side. I upvoted your answer, and would accept both, if I could. – noam Apr 23 '13 at 14:19
2

Somewhere in between returning full objects and just getting a string list, if the remote system is running V3, you can get a shallow deserialization via json:

ConvertFrom-Json (icm -comp server { gci -rec c:\ | convertto-json -Depth 1})

Edit:

Converting to/from csv gets you a (shallow) deserialized object, and actuall seems to run faster than out-string:

ConvertFrom-csv (icm -comp server { gci -rec c:\ | convertto-csv})
mjolinor
  • 66,130
  • 7
  • 114
  • 135
1

Yes, you're correct about the overhead of serializing/deserializing the FileInfo and DirectoryInfo objects over the wire. If you don't care about getting real objects, do something like this:

icm -comp server { gci -rec c:\ | out-string }

It should be an order of magnitude faster, at least.

x0n
  • 51,312
  • 7
  • 89
  • 111
  • Indeed, this took 3.3 minutes. Thanks. – noam Apr 19 '13 at 19:39
  • you can get pseudo objects back by using convertfrom-csv on the client side and convertto-csv on the server end (instead of out-string) and still have greatly improved speed. See @mjolinor's answer below. – x0n Apr 19 '13 at 19:49