I found the cause of the slower processing. You unwrapped the pipeline; it's
the difference between this

$fc = 'cmd /c dir c:\windows /b /s | findstr /r "\.txt$ .\log$" '

and this:

$fc = cmd /c dir /s /b c:\windows | findstr /r "\.txt$ \.log$"

The external single-quotes ensure that the piping into findstr is part of
cmd.exe's job, rather than PowerShell's, in the interest of speeding up the
initial processing.

Your test also confirms something else I suspected but wasn't sure about.
Once you've created pipeline objects, processing them with non-PowerShell
tools probably doesn't give any significant performance benefits, simply
because of the cost of flattening them into textstream objects and then
reconstituting them.



"Shay Levy [MVP]" <no@xxxxxx> wrote in message
news:89228ed2383d38cabbaf7e6b2162@xxxxxx

>

> PS > measure-command {cmd /c dir /s /b c:\windows | findstr /r "\.txt$
> \.log$"}

I removed the outer quotes cause otherwise the command is just a string,
PowerShell won't execute it (unless invoked):

PS > $fc = 'cmd /c dir c:\windows /b /s | findstr /r "\.txt$ .\log$" '
PS > $fc
cmd /c dir c:\windows /b /s | findstr /r "\.txt$ .\log$"


PS > measure-command {$fc = dir c:\windows -r -inc *.txt,*.log}

(...)
Seconds : 32
Milliseconds : 167
Ticks : 321679677
TotalDays : 0.000372314440972222
TotalHours : 0.00893554658333333
TotalMinutes : 0.536132795
TotalSeconds : 32.1679677
TotalMilliseconds : 32167.9677


PS > measure-command {$fc = iex 'cmd /c dir c:\windows /b /s | findstr /r
"\.txt$ .\log$" '}

(...)
Seconds : 25
Milliseconds : 29
Ticks : 250297940
TotalDays : 0.000289696689814815
TotalHours : 0.00695272055555556
TotalMinutes : 0.417163233333333
TotalSeconds : 25.029794
TotalMilliseconds : 25029.794


When invoked, the cmd expression is faster but it leaves you with raw strings
that you need to parse/concat and then use get-childitem to turn them into
full .net objects, and all of that can eventually take the precious seconds
we are trying to save. Which one is better/elegant? That's for the readers
to decide



---
Shay Levy
Windows PowerShell MVP
blog: http://blogs.microsoft.co.il/blogs/ScriptFanatic



A> I found the cause of the slower processing. You unwrapped the
A> pipeline; it's the difference between this
A>
A> $fc = 'cmd /c dir c:\windows /b /s | findstr /r "\.txt$ .\log$" '
A>
A> and this:
A>
A> $fc = cmd /c dir /s /b c:\windows | findstr /r "\.txt$ \.log$"
A>
A> The external single-quotes ensure that the piping into findstr is
A> part of cmd.exe's job, rather than PowerShell's, in the interest of
A> speeding up the initial processing.
A>
A> Your test also confirms something else I suspected but wasn't sure
A> about. Once you've created pipeline objects, processing them with
A> non-PowerShell tools probably doesn't give any significant
A> performance benefits, simply because of the cost of flattening them
A> into textstream objects and then reconstituting them.
A>
A> "Shay Levy [MVP]" <no@xxxxxx> wrote in message
A> news:89228ed2383d38cabbaf7e6b2162@xxxxxx
A>

>> PS > measure-command {cmd /c dir /s /b c:\windows | findstr /r
>> "\.txt$ \.log$"}
>>

Inline - interesting points here...

"Shay Levy [MVP]" <no@xxxxxx> wrote in message
news:uKMQAhc7IHA.1468@xxxxxx

>
> I removed the outer quotes cause otherwise the command is just a string,
> PowerShell won't execute it (unless invoked):

Using measure-command on it? I cheated and instead used get-date before and
after completion to do the measurement; not nearly so nice, but it let me at
least measure the darned thing .

> When invoked, the cmd expression is faster but it leaves you with raw
> strings that you need to parse/concat and then use get-childitem to turn
> them into full .net objects, and all of that can eventually take the
> precious seconds we are trying to save. Which one is better/elegant?
> That's for the readers to decide

I'm not touching the elegance issue. : )

As for better, there's only one situation where I think the cmd.exe choice
may be better. If you're trying to perform a file enumeration operation that
is simply too time-consuming with Get-ChildItem, and if it's a repeatable
problem, then using cmd.exe makes sense to me as a workaround - something
like putting inline assembler into a program in order to get around a
difficult problem, where the only alternative is not solving the problem at
all.

Of course, if this was a REALLY big demand, someone could write a nice C++
DLL to handle enumeration and name-based filtering, and then wrap it up in a
specialty PowerShell cmdlet to provide the best of both worlds.

As a side note, Get-ChileItem support the -name switch parameter, when specified
it retrieves only the names of the items. In terms of performance, it is
not that fast



---
Shay Levy
Windows PowerShell MVP
blog: http://blogs.microsoft.co.il/blogs/ScriptFanatic



A> Inline - interesting points here...
A>
A> "Shay Levy [MVP]" <no@xxxxxx> wrote in message
A> news:uKMQAhc7IHA.1468@xxxxxx
A>

>> I removed the outer quotes cause otherwise the command is just a
>> string, PowerShell won't execute it (unless invoked):
>>

A> Using measure-command on it? I cheated and instead used get-date
A> before and after completion to do the measurement; not nearly so
A> nice, but it let me at least measure the darned thing .
A>

>> When invoked, the cmd expression is faster but it leaves you with raw
>> strings that you need to parse/concat and then use get-childitem to
>> turn them into full .net objects, and all of that can eventually take
>> the precious seconds we are trying to save. Which one is
>> better/elegant? That's for the readers to decide
>>

A> I'm not touching the elegance issue. : )
A>
A> As for better, there's only one situation where I think the cmd.exe
A> choice may be better. If you're trying to perform a file enumeration
A> operation that is simply too time-consuming with Get-ChildItem, and
A> if it's a repeatable problem, then using cmd.exe makes sense to me as
A> a workaround - something like putting inline assembler into a program
A> in order to get around a difficult problem, where the only
A> alternative is not solving the problem at all.
A>
A> Of course, if this was a REALLY big demand, someone could write a
A> nice C++ DLL to handle enumeration and name-based filtering, and then
A> wrap it up in a specialty PowerShell cmdlet to provide the best of
A> both worlds.
A>

>
> someone could write a nice C++ DLL

Mmm so within PowerShell,
one is back again to using
Log Parser!

It's another Swiss Army Knife. ; )

"Flowering Weeds" <floweringnoweedsno@xxxxxx> wrote in message
news:e3z0pNo7IHA.2072@xxxxxx

>

>>
>> someone could write a nice C++ DLL

>
> Mmm so within PowerShell,
> one is back again to using
> Log Parser!
>
>