Remove some Linq usages from Kestrel.Core #47012
Conversation
eerhardt
requested review from
Tratcher,
halter73,
BrennanConroy,
JamesNK and
mgravell
as code owners
ghost
added
the
| @@ -179,7 +178,14 @@ public override CancellationToken ConnectionClosed | |||
|
|
|||
| public Task StopEndpointsAsync(List<EndpointConfig> endpointsToStop, CancellationToken cancellationToken) | |||
| { | |||
| var transportsToStop = _transports.Where(t => t.EndpointConfig != null && endpointsToStop.Contains(t.EndpointConfig)).ToList(); | |||
| var transportsToStop = new List<ActiveTransport>(); | |||
There was a problem hiding this comment.
How many do we expect? Almost none? Almost all? I'm thinking "list initial size" reasons
There was a problem hiding this comment.
At most it is _transports.Count. At minimum, it is 0. I'm not sure what the typical case would be.
This is only called on RebindAsync, which happens when the configuration changes and there are endpoints to stop.
There was a problem hiding this comment.
I'd leave it. There are much bigger optimizations we could make to endpoint rebinding if we cared more about this scenario. For example, we could start bringing new endpoints online before completely stopping all the removed ones if they don't conflict.
| @@ -179,7 +178,14 @@ public override CancellationToken ConnectionClosed | |||
|
|
|||
| public Task StopEndpointsAsync(List<EndpointConfig> endpointsToStop, CancellationToken cancellationToken) | |||
| { | |||
| var transportsToStop = _transports.Where(t => t.EndpointConfig != null && endpointsToStop.Contains(t.EndpointConfig)).ToList(); | |||
| var transportsToStop = new List<ActiveTransport>(); | |||
There was a problem hiding this comment.
I'd leave it. There are much bigger optimizations we could make to endpoint rebinding if we cared more about this scenario. For example, we could start bringing new endpoints online before completely stopping all the removed ones if they don't conflict.
| @@ -38,7 +38,20 @@ public class KestrelServerOptions | |||
| // The following two lists configure the endpoints that Kestrel should listen to. If both lists are empty, the "urls" config setting (e.g. UseUrls) is used. | |||
| internal List<ListenOptions> CodeBackedListenOptions { get; } = new List<ListenOptions>(); | |||
| internal List<ListenOptions> ConfigurationBackedListenOptions { get; } = new List<ListenOptions>(); | |||
| internal IEnumerable<ListenOptions> ListenOptions => CodeBackedListenOptions.Concat(ConfigurationBackedListenOptions); | |||
|
|
|||
| internal ListenOptions[] GetListenOptions() | |||
There was a problem hiding this comment.
Would it really be that bad to leave it as a property? It's not that expensive, and might be easier than tracking down all the tests.
There was a problem hiding this comment.
I can leave it as a property, but I really dislike allocating in a property getter.
There was a problem hiding this comment.
Question: are the two lists mutated much at the moment? Thery could be stored in a single list or array, with an int that marks the split between the two chunks. Then the combined list is "ignore the split", and the other two lists are just separate pieces of the single chunk - ideally returning either RwadOnlyMemory-ListenOptions, ReadOnlySpan-ListenOptions, or ArraySegment-ListenOptions. If it is easiest to use a list when building, theres a CollectionsMarshal API to sneak inside when needed
There was a problem hiding this comment.
From a quick investigation, for a dotnet new api template app, neither list is mutated.
The way CodeBackedListenOptions gets mutated is if someone adds endpoints in code, ex: builder.WebHost.ConfigureKestrel(o => o.ListenLocalhost(5556));.
The way ConfigurationBackedListenOptions get mutated is if someone adds endpoints through configuration, ex: builder.Configuration.AddInMemoryCollection(new Dictionary<string, string?>() { { "Kestrel:EndPoints:Http:Url", "http://localhost:5555" } });.
They are kept separate in order to correctly "reload" on configuration changes. Kestrel knows which ones were added by the previous configuration, and can remove any endpoints that are now removed.
I think your idea might be a good idea, but I think it is out of scope for this PR. Feel free to open a separate PR for it.
amcasey
added
area-networking
Similar to #47004, remove some Linq usages to reduce NativeAOT app size.
Unfortunately, these changes aren't yielding as big of a size impact. But since I made them, I figured I'd send a PR for them. If we don't think this is worth it, we can reject this PR.
On Windows x64, the BasicMinimalApi using
EnableRequestDelegateGenerator=true, the app size goes from:#47004: 9.56 MB (10,024,960 bytes)
PR: 9.54 MB (10,009,088 bytes)