Enumerate paramnames on startup

[marafiq]

Enumerate endpoint parameter names on startup instead of allocating a list.

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Summary of the changes

Use Enumerable instead of List to save allocation

Use of IEnumerable<string> when getting the endpoint parameters names from the collection, which then gets used to create the RequestDelegateFactoryContext

Fixes #46010

[ghost]

Thanks for your PR, @marafiq. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[dnfadmin]

All CLA requirements met.

[adityamandaleeka]

@mitchdenny Assigning this to you to look at since the corresponding issue is assigned to you.

[mitchdenny]

Also looping in @captainsafia since she would be interested in seeing the PR and is doing some stuff in AOT in this area.

On the surface this doesn't look like a breaking API change (good) - but in terms of performance impact in an actual application I don't think I can see the impact. One thing to point out with the benchmark is that you've got 10 route parameters - that is actually a lot when you consider even quite nested APIs such as:

/customers/{customer}/contacts/{contact}/addresses/{address}

I re-ran the benchmark with 3 route parameters and the results aren't quite as dramatic in that case:

|                          Method |      Mean |     Error |    StdDev |   Gen0 | Allocated |
|-------------------------------- |----------:|----------:|----------:|-------:|----------:|
|              Add10StringsToList | 58.127 ns | 1.1880 ns | 1.7414 ns | 0.0278 |     120 B |
|             Add10StringsToArray | 49.984 ns | 0.8905 ns | 0.8330 ns | 0.0204 |      88 B |
|     UseEnumerableWithLinqSelect | 21.989 ns | 0.3592 ns | 0.2999 ns | 0.0167 |      72 B |
| UseEnumerableWithLocalFuncYield |  9.093 ns | 0.2014 ns | 0.1978 ns | 0.0111 |      48 B |

Let's imagine an application with a modest number of 3 parameter routes (say a 10):

Scenario	Startup time contribution (10 * mean ns)	Memory contribution (10 * mean allocations)
Without optimization	580 nanoseconds	1200 bytes
With optimization	90 nanoseconds	480 bytes

[marafiq]

Thanks for taking a look at us @mitchdenny
Three route parameters for an endpoint are a good default. One thing to note is that the code will run for every endpoint with parameters.

but in terms of performance impact in an actual application I don't think I can see the impact

As you have seen in your benchmark run, there are slight improvements in allocation and some ns. There is not nothing else in terms of impact.

[mitchdenny]

Thanks for the contribution!

[halter73]

We will probably not merge this kind of micro-optimization unless it is on a really hot path in the future. If the optimization is large enough that it would show a statistically significant impact on the overall RequestDelegateFactory.Create(Delegate) call, that would be a different story.

That said, I appreciate the initiative! Given that the microbenchmark shows an improvement, and that the code is as easy to follow as it was before imo, I think we should merge the PR this time.

Thanks for contributing!