Powershell: Get-ChildItem 3x: Replace NoteProperties on FileSystem- and RegistryProvider by class backed CodeProperties.

[powercode]

When using Get-ChildItem, the ProviderBase adds these note properties:

PSDrive
PSIsContainer
PSParentPath
PSPath
PSProvider

This is quite expensive, both in terms of memory and execution time.

By replacing the noteproperties with a classes that lazily can compute most of the values, we can save both storage and time.

Timing:

Command | 6.1-preview | After change | Speedup
-------------------------------------- | ------------ | --------------- | ----------
GCI -rec -for d:\source\powershell | 0.446 | 0.144 | 3.1 x
GCI -rec -for c:\windows -ea:0 | 12.24 | 6.05 | 2 x
GCI -rec hkcu:\ -ea:0 | 7.86 | 2.99 | 2.6 x

Cred to @lzybkr - this was his idea, not mine.

[powercode]

Memory:

The yellow is after the change.
This was measured before and after running

Get-ChildItem -Recurse -Force d:\source\powershell

A quite substantial memory reduction.

[powercode]

One thing to consider is if it is OK to add CodeProperties to System.IO.FileInfo and System.IO.DirectoryInfo.

[Jaykul]

The classes in question (e.g. system.io.fileinfo) are sealed, meaning you can't just inherit from them... so what did you test? (Nevermind, I looked at the PR).

So you can definitely add properties in the TypeData as CodeProperty (resulting in a lazy load, but still C# evaluation) instead of adding them as pre-calculated NoteProperty ... There is no question of whether that's "ok" (To implement the property as a static on a helper class). I'd say, if TypeData properties work for output from provider cmdlets, then it makes sense to me to do it that way!

I think to get the full picture of perf. you'd need to test it piping through other commands, since so many of them use the PSPath property, for instance get-childitem | get-item ... or something.

[powercode]

@Jaykul I was more thinking about the use case when you instantiate the FileInfo by newing it up. Then it will not have the backing property object, and these CodeProperties will still be there, but empty.

That is a change from before, when these properties was not there at all, since they are added per instance by the provider.

[iSazonov]

Should we ask PowerShell Committee? /cc @SteveL-MSFT @daxian-dbw

[Jaykul]

@powercode I would still say that I can't imagine how adding those properties through ETS could cause a problem. 😁

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this. Would suggest putting this feature behind an experimental flag to determine if this breaks any customers.

[powercode]

I completely agree. This is kind of an experiment right now - I'm also looking at derived PSObject types and changing the binders. That seems to have more potential performance wise. Both should probably be behind an experimental flag.