Optimize Get-ChildItem -Recurse -Name

[iSazonov]

PR Summary

Addresses #9119

Intention is to improve performance without changing current behavior. Later we can more easily fix already known bugs/inconsistencies and add new features.

Performance win is up to 50%.
Allocations are dramatically reduces if filtering is used (now no allocations are for discarded paths).

• Use new .Net Runtime path (folder/file) enumerator in PowerShell file system provider.
• Refactor existing code to one method.
• Add more tests (mainly for hidden file attribute)

Today the .Net API does not support:

• Depth (tracking issue) and we use a workaround in the case.
• ContinueOnError predicate and we use copy-pasted and bit enhanced code from .Net.

PR Context

Current implementation is a generic (common for all providers) enumerating code which is very expensive. New implementation uses new .Net API for file enumerating. The API is very fast and efficient, especially if filtering is used.

The follow intention is to use this approach later for dir -recurse too and then fix known bugs and add new features.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[ghost]

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

[ghost]

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author