Avoid delegate allocation in NamedPipeClientStream.ConnectAsync #68752
Conversation
We still need to allocate an object for the closed-over state, but we can avoid the per-call delegate allocation.
|
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsWe still need to allocate an object for the closed-over state, but we can avoid the per-call delegate allocation.
|
ghost
assigned
danmoseley
left a comment
danmoseley
left a comment
There was a problem hiding this comment.
Did we / should we do a pass for other places that could benefit from translating to a static lambda? Eg., at random
RequestQueue<HttpConnection>.QueueItem queueItem = _http11RequestQueue.PeekNextRequestForConnectionAttempt();
Task.Run(() => AddHttp11ConnectionAsync(queueItem));
|
I actually don't have a good intuition for these things, and why the compiler or runtime can't do this transformation when possible. |
|
| int startTime = Environment.TickCount; // We need to measure time here, not in the lambda | ||
| return Task.Run(() => ConnectInternal(timeout, cancellationToken, startTime), cancellationToken); | ||
|
|
||
| return Task.Factory.StartNew(static state => |
There was a problem hiding this comment.
Why Task.Factory.StartNew -- so you could pass DenyChildAttach?
There was a problem hiding this comment.
I believe it's just because Task.Factory.StartNew accepts a state object, whereas Task.Run doesn't.
There was a problem hiding this comment.
because Task.Factory.StartNew accepts a state object
Right
|
Ha, I hadn't seen that. Is Task.Run without 'static' the code smell? eg edit: never mind, there's clearly already a delegate allocated in that case. OK, I don't see significant other cases then. |
3 participants
We still need to allocate an object for the closed-over state, but we can avoid the per-call delegate allocation.