-Filter vs Where-Object in a Get-WmiObject command

So, I’ve always known -Filter (where available) to run much quicker than piping the results of a search to Where-Object, since the second option requires gathering all of the information, then parsing it. I’m hoping someone can explain this:

Measure-command {Get-WmiObject -Class Win32_Product -Filter "name LIKE 'Putty%'"}

TotalSeconds : 19.3040678

Measure-command {Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "Putty*"}}

TotalSeconds : 19.2802772

Why is piping the results to Where-Object running quicker than declaring a filter?

It’s always situation dependent. And a couple hundredths of a second isn’t really any different. When you’re not working with huge amounts of data, it isn’t always significant, and in this case it depends on how well the underlying WMI provider is written. It may be doing the same thing - getting every instance and then enumerating.

Since Get-WmiObject is just getting instances of WMI classes, is it safe to assume that most (if not all) WMI class queries would operate the same?
Or would that, again, be a case-by-case basis based on how the query was written?

No. WMI isn’t one big thing, it’s a dozen little things. Win32_Product isn’t served out of the “core” WMI provider set; it’s served by its own provider. Different software being served through the same interface. Win32_Product in particular doesn’t store much in the actual repository - it has to actively query data each time you use it. Since there’s no “cached” data copy, you’re likely to see the same performance regardless. Win32_Product is known to be fairly poorly written, relative to some other providers. Not entirely it’s fault, as it has to deal with Windows Installer, which ain’t a hot shot either.