Skip to content

Fix Start-Benchmarking to put TargetPSVersion and TargetFramework in separate parameter sets - #15508

Merged
Andrew (anmenaga) merged 1 commit into
PowerShell:masterfrom
daxian-dbw:perf
Jun 11, 2021
Merged

Fix Start-Benchmarking to put TargetPSVersion and TargetFramework in separate parameter sets#15508
Andrew (anmenaga) merged 1 commit into
PowerShell:masterfrom
daxian-dbw:perf

Conversation

@daxian-dbw

@daxian-dbw Dongbo Wang (daxian-dbw) commented Jun 2, 2021

Copy link
Copy Markdown
Member

PR Summary

Fix Start-Benchmarking to put TargetPSVersion and TargetFramework in separate parameter sets
For a specific version of PowerShell SDK, we want to run benchmarks with it targeting the latest .NET runtime, so that we are comparing only the differences in the PowerShell implementation.

PR Checklist

@daxian-dbw

Copy link
Copy Markdown
Member Author

Andrew (@anmenaga) The CIs won't run for files under the path test/perf, because files there don't affect production code or tests.

Comment thread test/perf/perf.psm1
[Parameter(ParameterSetName = 'Default')]
[Parameter(ParameterSetName = 'TargetPSVersion')]
[ValidatePattern(
'^7\.(0|1|2)\.\d+(-preview\.\d{1,2})?$',

@vexx32 Rain Sallow (/u/ta11ow) (vexx32) Jun 10, 2021

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Defining the pattern in this way requires that it be updated for every new minor (and/or major) PSVersion. This seems like there should be a better way; is there not a way the function can check the supplied version against an automatically-determined list of possible versions?

@daxian-dbw Dongbo Wang (daxian-dbw) Jun 10, 2021

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the current validation is not optimal. In fact, not just here, the powershell-perf.csproj also requires manual updates when we move to a new PS version or new .NET runtime, because it hardcodes the supported .NET frameworks, as well as the latest PS version corresponding to a specific .NET framework. It would be nice if we can avoid the need of manual updates to both perf.psm1 and powershell-perf.csproj. Anyways, that should be a separate PR 😄

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could move this in a json config file.

@anmenaga Andrew (anmenaga) added CL-Test Indicates that a PR should be marked as a test change in the Change Log CL-Performance Indicates that a PR should be marked as a performance improvement in the Change Log and removed CL-Performance Indicates that a PR should be marked as a performance improvement in the Change Log labels Jun 11, 2021
@anmenaga
Andrew (anmenaga) merged commit 6c8d7c0 into PowerShell:master Jun 11, 2021
@ghost

Copy link
Copy Markdown

🎉v7.2.0-preview.7 has been released which incorporates this pull request.:tada:

Handy links:

Thatgfsj (Thatgfsj) pushed a commit to Thatgfsj/PowerShell that referenced this pull request Aug 6, 2026
…k' in separate parameter sets (PowerShell#15508)

The CIs won't run for files under the path test/perf, because files there don't affect production code or tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-Test Indicates that a PR should be marked as a test change in the Change Log

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants