Skip calling dotnet --info by using --list-x --arch when available
#2296
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dotnet/runtime#116078 --arch was not added until .NET 10 to allow us to skip calling dotnet --info because that is slow, as it is not native code. // However, --arch gets ignored if the host does not support it. The output is also identical with or without --arch. // After discussion with the runtime team, the best way to determine if the host supports --arch is to call it with an invalid arch to see if it fails, because that only happens when --arch is supported. // The --arch flag was added in the middle of .NET 10, so we can assume it is supported if the version is 10.0 or later. // We don't want to slow down the current common case for people without .NET 10 by adding another process spawn check. // We don't check that the version is 10.0 or later after 2026 when .NET 11 starts rolling out, as It will be slower to check all of the numbers in the output for versions >= 10.
Also support .NET 11 behavior while its in pre-release
…de-dotnet-runtime into nagilson-skip-info
they take longer now that they need to execute commands
MiYanni
approved these changes
Jun 5, 2025
Comment on lines
+156
to
+158
| // https://github.com/dotnet/runtime/pull/116078 --arch was not added until .NET 10 to allow us to skip calling dotnet --info because that is slow, as it is not native code. | ||
| // However, --arch gets ignored if the host does not support it. The output is also identical with or without --arch. | ||
| // After discussion with the runtime team, the best way to determine if the host supports --arch is to call it with an invalid arch to see if it fails, because that only happens when --arch is supported. |
There was a problem hiding this comment.
This is more of an aloud note to myself, but it is obviously a problem that we have no clear delineation between native-based and non-native-based CLI operations. And the other problem is that the perf between those is so vastly different. I know AOT was discussed, but there must be a non-AOT solution and a solution that doesn't require pushing more functionality into the host itself (native code). 🤔
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
dotnet --inforesolves in the sdk (C# code) instead of the host (C++) code. It also resolves workloads and a slew of other JIT-ed components which makes it very 'slow' in comparison to host commands.We only call --info to get the architecture of an existing install. Thus, after some discussion in my issue here: dotnet/runtime#108503, the runtime team dotnet/runtime#116078 added support for
dotnet --list-runtimes --archand the same for--list-sdks.What this flag does is show the installs that match the specified architecture given in arch.
The previous behavior ignored other flags and also only printed what matched the host architecture (unknown, which is what we got from info.)
I've utilized this new API to improve performance by skipping
dotnet --infowhen applicable. We still need to call it for some .NET hosts before the .NET 10 hosts that have this functionality. And the easiest way to check is by seeing if --arch invalid fails or not (in which case, it supports--arch.) This is somewhat unfortunate as it is slower, but the best we came up with. (See discussion in the aforementioned PR.) I added some rudimentary logic to skip this --arch support check, if the host is already known to be too old (e.g. younger than .NET 10) to prevent this from slowing down the existing scenario too much (most people are on .NET 8.) I also time-gated it to always check after a certain point, as mentioned in the comments. Somewhat hacky, but probably sufficient.