Remove queue-subdispatching pattern to the ThreadPool global queue

[VSadov]

To avoid allocating a workitem per every socket/IO event and reduce the number of enqueues to the global queue we use the following pattern:

• Socket/IO engine places the events (a struct) into a concurrent queue, where the storage is naturally reused.
• In order to get the event executed, we post a self-replicating workitem into a global queue and that workitem fetches the events and executes them.
• There is also a heuristic that if the queue runs dry or after some time duration (and in Windows case also in a presence of local workitems) the task stops "pumping" of the events would not starve other workitems.

=== The pattern has some issues that get worse on big core counts:

• The self-replication of the event queue task places copies of itself into the global queue every time a worker starts "pumping" and sees more items in the queue. We must do this for correctness - to make sure that remaining queued events will be eventually picked up even if the current thread blocks.
  This self-requeuing can put a lot of stress on the global queue.
  In a case of assignable queues, the re-queued item ends up in the assignable queue, which are local to a subset of workers, thus may impact p99 latencies.

• When a worker stops dispatching from the event queue (due to time limit, for example) and then picks up an event queue task again, it may be a queue from a different IO engine.
  This randomizes both the assignment of the event queues to workers and the order of event execution.
  It is possible that multiple workers would "pump" events from the same queue, while other queues are neglected (and keep growing if events are arriving).
  A queue that is overshared may cause contentions, spinning/sleeping of workers.

• the event queue is basically a memory cache with no upper bounds. We do not know how big the event queue can get if the enqueuing outruns dequeuing for some nontrivial time.
  We do not report the size of this queue in the ThreadPool Queue Length or any other counter even though these are technically threadpool workitems.

=== What we do instead in this PR:
At the high level instead of relying on a queue to reduce the number of global enqueues (temporal batching), we explicitly combine multiple events into batches of predictable and bounded size and enqueue entire batches to the global queue.

Details:

• IO engine fills actual event workitems (in IThreadPoolWorkItem sense) with data.

• The workitems are reused via a pool that has an upper bound.
  (in an unlikely case that the limit is reached we will allocate/GC the workitems).

• To avoid stressing the global queues, the workitems are packed into balanced binary trees, so that we could submit the entire batch for execution in one enqueue.

• Worker threads, upon executing the parent, place the children into the local queue.
  The current worker is likely still the best worker to execute the children, but if other workers need work they can steal whole subtrees thus divide-and-conquering the remaining work.

• as a general approach if execution of an event results in more than one task, we place the additional tasks into the local queue - to relieve the stress on the global queue, improve the locality of execution and statistically reduce the max workqueue lengths.

• the size of a batch is bounded to make sure that large batches do not impact p99 latency.

=== Perf diffs:

JSON benchmarks

 x64 / HIGH load (56 cores, load 4096 connections, load threads=64)
- base RPS 2,528,080 p50 1.47 ms p99 3.79 ms+ new RPS 2,580,722 p50 1.50 ms p99 3.13 ms
+2.1% +2.0% -17.4%
x64 / LOW load (56 cores, load 512 connections)
- base RPS 2,141,591 p50 0.21 ms p99 0.57 ms+ new RPS 2,177,068 p50 0.21 ms p99 0.59 ms
+1.7% 0.0% +3.5%
arm64 / HIGH load (96 cores, load 4096 connections, load threads=64)
- base RPS 3,715,921 p50 0.57 ms p99 7.30 ms+ new RPS 3,696,351 p50 0.56 ms p99 7.01 ms
-0.5% -1.8% -4.0%
arm64 / LOW load (96 cores, load 256 connections)
- base RPS 2,064,045 p50 0.25 ms p99 0.78 ms+ new RPS 2,149,487 p50 0.25 ms p99 0.44 ms
+4.1% 0.0% -43.6%

The change appears to erase most of the gap with net10 on JSON benchmark in high core configuration, thus:
Fixes: #127484

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR changes how socket / IO completion events are dispatched to the thread pool, replacing the prior “queue + pumping work item” pattern with pooled per-event work items that are submitted in batches via a balanced binary tree to reduce global-queue pressure and bound memory growth.

Changes:

• Remove the Windows-only ThreadPoolTypedWorkItemQueue sub-dispatcher from ThreadPoolWorkQueue.
• Windows IOCP: pool IOCompletionPoller.Event instances and batch-submit completions as a balanced tree, fanning out to local queues as nodes execute.
• Unix sockets: pool SocketIOEvent instances and similarly batch-submit async socket events as a balanced tree; adjust some preferLocal scheduling.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs	Removes the Windows-only typed work item queue implementation previously used for IO sub-dispatch.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs	Introduces pooled Event work items and balanced-tree batching for IOCP completions; changes queueing behavior.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs	Reworks async socket event dispatch to use pooled SocketIOEvent work items and balanced-tree batching.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs	Switches some thread-pool queueing to preferLocal: true for async operation processing/cancellation callbacks.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• Using ConcurrentQueue<T>.Count in the hot path (SocketIOEvent.Execute) can be quite expensive under contention (Count is not O(1) for ConcurrentQueue<T>). Since this runs per completion, it risks regressing throughput and adding cross-thread cache contention. Consider tracking pool size with an explicit int counter (Interlocked increment/decrement on enqueue/dequeue) instead of calling Count here.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• Using ConcurrentQueue<T>.Count in Event.Execute is a potentially expensive operation under contention (Count is not O(1) for ConcurrentQueue<T>). Since this executes per IO completion, it can add avoidable overhead. Consider tracking pool size with an explicit Interlocked counter on borrow/return instead of querying Count here.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it for every completion work item defeats some of the intended perf/throughput wins.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it on every async socket event adds overhead on the hot path.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:102

• The comment above _eventQueue says it’s a queue of events generated by EventLoop, but in this revision _eventQueue is used as a pool of reusable SocketIOEvent instances (see RentEvent and SocketIOEvent.Execute). Updating the comment would prevent future confusion about its semantics and why it’s bounded.

 //
// Queue of events generated by EventLoop() that would be processed by the thread pool
//
private readonly ConcurrentQueue<SocketIOEvent> _eventQueue = new ConcurrentQueue<SocketIOEvent>();

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:512

• Event pooling uses ConcurrentQueue.Count on every completion to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock (see ConcurrentQueue.cs), so calling it in this hot path can add contention/latency and offset the intended allocation savings. Consider using an Interlocked-based approximate pool size counter (increment on Enqueue, decrement on Dequeue) instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:527

• SocketIOEvent pooling uses ConcurrentQueue.Count on every event execution to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock, so this can be a measurable hot-path cost under high IO rates. Consider tracking pool size via an Interlocked counter (increment on Enqueue, decrement on RentEvent dequeue success) instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:509

• Using ConcurrentQueue.Count on every IO completion to enforce the pool bound is potentially expensive. ConcurrentQueue.Count can spin and may take _crossSegmentLock when there are multiple segments (see System.Collections.Concurrent.ConcurrentQueue.Count implementation), which can become a noticeable overhead at high IO rates. Consider tracking pool size with an Interlocked counter (increment on Enqueue, decrement on successful TryDequeue) to keep the bound check O(1) without extra locking.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:533

• SocketIOEvent.Execute() uses ConcurrentQueue.Count to enforce the pool bound. ConcurrentQueue.Count can spin and may take the cross-segment lock when multiple segments exist, so doing this per event can add measurable overhead under heavy IO. Consider maintaining an Interlocked pool-size counter instead of calling Count in the hot path.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue<T>.Count can take _crossSegmentLock (and spin/retry) when the queue has multiple segments, so calling _pool.Count on every completion is a potentially expensive hot-path operation and undermines the goal of reducing overhead. Consider tracking the pool size with an int updated via Interlocked on enqueue/dequeue (best-effort is fine) and use that value for the MaxEventPoolCount check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• _pool.Count is queried for every SocketIOEvent execution. ConcurrentQueue<T>.Count is not a cheap counter; it may spin and can take _crossSegmentLock when multiple segments exist, so this can become a measurable overhead under high event rates. Consider maintaining an int pool size updated via Interlocked on enqueue/dequeue and using that for the MaxEventPoolCount gate instead of Count.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[VSadov]

@MihuBot benchmark System.Threading

[VSadov]

@MihuBot benchmark System.Buffers

[MihuBot]

System.Threading.Tests.Perf_Volatile

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Write_double	Main	0.9338 ns	0.0040 ns	1.00	-	NA
Write_double	PR	0.9317 ns	0.0029 ns	1.00	-	NA
Read_double	Main	0.9485 ns	0.0045 ns	1.00	-	NA
Read_double	PR	0.9459 ns	0.0064 ns	1.00	-	NA

System.Threading.Tests.Perf_Timer

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ShortScheduleAndDispose	Main	74.99 ns	0.395 ns	1.00	120 B	1.00
ShortScheduleAndDispose	PR	75.45 ns	0.697 ns	1.01	120 B	1.00
LongScheduleAndDispose	Main	75.44 ns	0.651 ns	1.00	120 B	1.00
LongScheduleAndDispose	PR	75.34 ns	0.673 ns	1.00	120 B	1.00
ScheduleManyThenDisposeMany	Main	223,379,838.13 ns	1,965,673.532 ns	1.00	144001328 B	1.00
ScheduleManyThenDisposeMany	PR	223,129,600.73 ns	2,591,171.964 ns	1.00	144001328 B	1.00
ShortScheduleAndDisposeWithFiringTimers	Main	80.28 ns	1.599 ns	1.00	144 B	1.00
ShortScheduleAndDisposeWithFiringTimers	PR	80.46 ns	1.515 ns	1.00	144 B	1.00
SynchronousContention	Main	1,420,584,665.07 ns	17,411,095.255 ns	1.00	1152000760 B	1.00
SynchronousContention	PR	1,298,023,677.18 ns	25,870,105.978 ns	0.91	1152000760 B	1.00
AsynchronousContention	Main	1,128,918,393.85 ns	36,890,792.880 ns	1.00	1152002232 B	1.00
AsynchronousContention	PR	1,403,692,668.40 ns	41,823,779.338 ns	1.25	1152002232 B	1.00

System.Threading.Tests.Perf_ThreadStatic

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
GetThreadStatic	Main	1.869 ns	0.0084 ns	1.00	-	NA
GetThreadStatic	PR	1.886 ns	0.0068 ns	1.01	-	NA
SetThreadStatic	Main	3.271 ns	0.0107 ns	1.00	-	NA
SetThreadStatic	PR	3.272 ns	0.0150 ns	1.00	-	NA

System.Threading.Tests.Perf_ThreadPool

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1 Gen0=38000.0000

Method	Toolchain	WorkItemsPerCore	Mean	Error	Ratio	Allocated	Alloc Ratio
QueueUserWorkItem_WaitCallback_Throughput	Main	20000000	1.980 s	0.0144 s	1.00	610.35 MB	1.00
QueueUserWorkItem_WaitCallback_Throughput	PR	20000000	1.965 s	0.0112 s	0.99	610.35 MB	1.00

System.Threading.Tests.Perf_Thread

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
CurrentThread	Main	1.895 ns	0.0140 ns	1.00	-	NA
CurrentThread	PR	1.892 ns	0.0078 ns	1.00	-	NA
GetCurrentProcessorId	Main	2.321 ns	0.0074 ns	1.00	-	NA
GetCurrentProcessorId	PR	2.119 ns	0.0111 ns	0.91	-	NA

System.Threading.Tests.Perf_SpinLock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	10.560 ns	0.0062 ns	1.00	-	NA
EnterExit	PR	10.553 ns	0.0124 ns	1.00	-	NA
TryEnterExit	Main	10.564 ns	0.0055 ns	1.00	-	NA
TryEnterExit	PR	10.546 ns	0.0044 ns	1.00	-	NA
TryEnter_Fail	Main	1.236 ns	0.0054 ns	1.00	-	NA
TryEnter_Fail	PR	1.233 ns	0.0050 ns	1.00	-	NA

System.Threading.Tests.Perf_SemaphoreSlim

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReleaseWait	Main	29.63 ns	0.016 ns	1.00	-	NA
ReleaseWait	PR	29.65 ns	0.014 ns	1.00	-	NA
ReleaseWaitAsync	Main	28.25 ns	0.021 ns	1.00	-	NA
ReleaseWaitAsync	PR	28.26 ns	0.011 ns	1.00	-	NA
ReleaseWaitAsync_WithCancellationToken	Main	317.66 ns	20.687 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithCancellationToken	PR	317.60 ns	22.628 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithTimeout	Main	337.80 ns	17.205 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithTimeout	PR	318.12 ns	7.530 ns	0.94	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	Main	361.32 ns	11.905 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	PR	362.21 ns	17.881 ns	1.00	624 B	1.00

System.Threading.Tests.Perf_Monitor

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	13.55 ns	0.008 ns	1.00	-	NA
EnterExit	PR	13.55 ns	0.006 ns	1.00	-	NA
TryEnterExit	Main	13.55 ns	0.009 ns	1.00	-	NA
TryEnterExit	PR	13.54 ns	0.007 ns	1.00	-	NA

System.Threading.Tests.Perf_Lock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReaderWriterLockSlimPerf	Main	13.55 ns	0.008 ns	1.00	-	NA
ReaderWriterLockSlimPerf	PR	13.55 ns	0.034 ns	1.00	-	NA

System.Threading.Tests.Perf_Interlocked

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Increment_int	Main	4.824 ns	0.0021 ns	1.00	-	NA
Increment_int	PR	4.820 ns	0.0040 ns	1.00	-	NA
Decrement_int	Main	4.829 ns	0.0159 ns	1.00	-	NA
Decrement_int	PR	4.819 ns	0.0018 ns	1.00	-	NA
Increment_long	Main	4.818 ns	0.0025 ns	1.00	-	NA
Increment_long	PR	4.820 ns	0.0016 ns	1.00	-	NA
Decrement_long	Main	4.815 ns	0.0020 ns	1.00	-	NA
Decrement_long	PR	4.820 ns	0.0025 ns	1.00	-	NA
Add_int	Main	4.815 ns	0.0016 ns	1.00	-	NA
Add_int	PR	4.816 ns	0.0022 ns	1.00	-	NA
Add_long	Main	4.817 ns	0.0019 ns	1.00	-	NA
Add_long	PR	4.819 ns	0.0019 ns	1.00	-	NA
Exchange_int	Main	4.819 ns	0.0033 ns	1.00	-	NA
Exchange_int	PR	4.819 ns	0.0048 ns	1.00	-	NA
Exchange_long	Main	4.817 ns	0.0020 ns	1.00	-	NA
Exchange_long	PR	4.820 ns	0.0020 ns	1.00	-	NA
CompareExchange_int	Main	4.829 ns	0.0024 ns	1.00	-	NA
CompareExchange_int	PR	4.830 ns	0.0019 ns	1.00	-	NA
CompareExchange_long	Main	4.832 ns	0.0037 ns	1.00	-	NA
CompareExchange_long	PR	4.831 ns	0.0033 ns	1.00	-	NA
CompareExchange_object_Match	Main	5.509 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_Match	PR	5.508 ns	0.0035 ns	1.00	-	NA
CompareExchange_object_NoMatch	Main	5.510 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_NoMatch	PR	5.508 ns	0.0041 ns	1.00	-	NA

System.Threading.Tests.Perf_EventWaitHandle

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Set_Reset	Main	42.75 ns	0.027 ns	1.00	-	NA
Set_Reset	PR	42.72 ns	0.020 ns	1.00	-	NA

System.Threading.Tests.Perf_CancellationToken

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
RegisterAndUnregister_Serial	Main	18.912 ns	0.0493 ns	1.00	-	NA
RegisterAndUnregister_Serial	PR	18.946 ns	0.1112 ns	1.00	-	NA
Cancel	Main	54.448 ns	0.8583 ns	1.00	192 B	1.00
Cancel	PR	53.189 ns	0.3285 ns	0.98	192 B	1.00
CreateLinkedTokenSource1	Main	21.830 ns	0.3112 ns	1.00	64 B	1.00
CreateLinkedTokenSource1	PR	21.034 ns	0.4128 ns	0.96	64 B	1.00
CreateLinkedTokenSource2	Main	38.236 ns	0.4997 ns	1.00	80 B	1.00
CreateLinkedTokenSource2	PR	37.323 ns	0.1491 ns	0.98	80 B	1.00
CreateLinkedTokenSource3	Main	58.207 ns	0.3793 ns	1.00	128 B	1.00
CreateLinkedTokenSource3	PR	58.819 ns	0.3601 ns	1.01	128 B	1.00
CreateTokenDispose	Main	5.448 ns	0.0367 ns	1.00	48 B	1.00
CreateTokenDispose	PR	5.462 ns	0.0467 ns	1.00	48 B	1.00
CreateRegisterDispose	Main	32.044 ns	0.3211 ns	1.00	192 B	1.00
CreateRegisterDispose	PR	31.946 ns	0.3375 ns	1.00	192 B	1.00
CreateManyRegisterDispose	Main	14.507 ns	0.0215 ns	1.00	-	NA
CreateManyRegisterDispose	PR	14.487 ns	0.0178 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	Main	80.629 ns	0.1873 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	PR	81.699 ns	0.1683 ns	1.01	-	NA
CancelAfter	Main	51.286 ns	0.3029 ns	1.00	144 B	1.00
CancelAfter	PR	52.058 ns	1.7330 ns	1.02	144 B	1.00

System.Threading.Tasks.Tests.Perf_AsyncMethods

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EmptyAsyncMethodInvocation	Main	3.731 ns	0.0128 ns	1.00	-	NA
EmptyAsyncMethodInvocation	PR	3.286 ns	0.0038 ns	0.88	-	NA
SingleYieldMethodInvocation	Main	102.221 ns	5.3328 ns	1.00	96 B	1.00
SingleYieldMethodInvocation	PR	100.185 ns	4.8837 ns	0.98	96 B	1.00
Yield	Main	30.483 ns	0.5967 ns	1.00	-	NA
Yield	PR	30.693 ns	1.1908 ns	1.01	-	NA

System.Threading.Tasks.ValueTaskPerfTest

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-UXTJFQ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-WCARJH : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-XVCCJK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HMQJNI : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MaxWarmupIterationCount=10 MinIterationCount=15
MinWarmupIterationCount=2 WarmupCount=-1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Await_FromResult	Main	5.328 ns	0.0110 ns	1.00	-	NA
Await_FromResult	PR	5.446 ns	0.0079 ns	1.02	-	NA
Await_FromCompletedTask	Main	9.748 ns	0.1823 ns	1.00	72 B	1.00
Await_FromCompletedTask	PR	9.318 ns	0.1712 ns	0.96	72 B	1.00
Await_FromCompletedValueTaskSource	Main	15.410 ns	0.2158 ns	1.00	72 B	1.00
Await_FromCompletedValueTaskSource	PR	15.242 ns	0.1697 ns	0.99	72 B	1.00
CreateAndAwait_FromResult	Main	5.281 ns	0.0154 ns	1.00	-	NA
CreateAndAwait_FromResult	PR	5.294 ns	0.0182 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	Main	5.276 ns	0.0160 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	PR	5.312 ns	0.0280 ns	1.01	-	NA
CreateAndAwait_FromCompletedTask	Main	5.774 ns	0.0214 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask	PR	5.914 ns	0.0899 ns	1.02	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	Main	5.817 ns	0.0137 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	PR	6.211 ns	0.0136 ns	1.07	-	NA
CreateAndAwait_FromCompletedValueTaskSource	Main	6.762 ns	0.0108 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource	PR	6.319 ns	0.0094 ns	0.93	-	NA
CreateAndAwait_FromYieldingAsyncMethod	Main	204.260 ns	9.2949 ns	1.00	207 B	1.00
CreateAndAwait_FromYieldingAsyncMethod	PR	212.860 ns	13.1086 ns	1.04	207 B	1.00
CreateAndAwait_FromDelayedTCS	Main	77.672 ns	0.3388 ns	1.00	216 B	1.00
CreateAndAwait_FromDelayedTCS	PR	76.081 ns	0.5506 ns	0.98	216 B	1.00
Copy_PassAsArgumentAndReturn_FromResult	Main	2.842 ns	0.0268 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromResult	PR	2.832 ns	0.0272 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	Main	5.853 ns	0.0244 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	PR	6.085 ns	0.0314 ns	1.04	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	Main	8.025 ns	0.0529 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	PR	7.993 ns	0.0522 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	Main	6.334 ns	0.0582 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	PR	6.310 ns	0.0456 ns	1.00	-	NA

System.Threading.Channels.Tests.UnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	30.37 ns	0.041 ns	1.00	-	NA
TryWriteThenTryRead	PR	30.40 ns	0.034 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	30.35 ns	0.029 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	30.35 ns	0.019 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	49.04 ns	0.016 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	49.30 ns	0.207 ns	1.01	-	NA
PingPong	Main	2,627,902.03 ns	111,019.119 ns	1.00	903 B	1.00
PingPong	PR	2,658,820.31 ns	145,066.288 ns	1.01	901 B	1.00

System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	17.54 ns	0.013 ns	1.00	-	NA
TryWriteThenTryRead	PR	17.54 ns	0.010 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	22.39 ns	0.016 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	22.43 ns	0.025 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	46.94 ns	0.020 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	47.04 ns	0.076 ns	1.00	-	NA
PingPong	Main	2,511,563.26 ns	93,531.184 ns	1.00	901 B	1.00
PingPong	PR	2,627,531.08 ns	129,689.322 ns	1.05	900 B	1.00

System.Threading.Channels.Tests.BoundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	35.91 ns	0.031 ns	1.00	-	NA
TryWriteThenTryRead	PR	35.87 ns	0.019 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	37.57 ns	0.044 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	37.61 ns	0.061 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	47.84 ns	0.043 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	48.03 ns	0.038 ns	1.00	-	NA
PingPong	Main	2,893,666.76 ns	138,789.838 ns	1.00	901 B	1.00
PingPong	PR	2,847,279.72 ns	148,677.365 ns	0.99	901 B	1.00

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/ea54990edbbdbf16145eaa382580240f

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Calling it on every IO completion can become a noticeable CPU cost exactly when the pool is large. Consider enforcing MaxEventPoolCount with a separate Interlocked-updated counter (increment when returning an Event to the pool, decrement when renting) so the hot path avoids Count while still bounding growth.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Checking it on every SocketIOEvent.Execute() adds avoidable overhead on a very hot path and becomes more expensive as the pool grows. Consider tracking an explicit pool size counter (Interlocked) so MaxEventPoolCount can be enforced without calling Count per completion.

 if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[eduardo-vp]

LGTM!

[VSadov]

Thanks!

[VSadov]

To avoid allocating a workitem per every socket/IO event and reduce the number of enqueues to the global queue we use the following pattern:

• Socket/IO engine places the events (a struct) into a concurrent queue, where the storage is naturally reused.
• In order to get the event executed, we post a self-replicating workitem into a global queue and that workitem fetches the events and executes them.
• There is also a heuristic that if the queue runs dry or after some time duration (and in Windows case also in a presence of local workitems) the task stops "pumping" of the events would not starve other workitems.

=== The pattern has some issues that get worse on big core counts:

• The self-replication of the event queue task places copies of itself into the global queue every time a worker starts "pumping" and sees more items in the queue. We must do this for correctness - to make sure that remaining queued events will be eventually picked up even if the current thread blocks.
  This self-requeuing can put a lot of stress on the global queue.
  In a case of assignable queues, the re-queued item ends up in the assignable queue, which are local to a subset of workers, thus may impact p99 latencies.

• When a worker stops dispatching from the event queue (due to time limit, for example) and then picks up an event queue task again, it may be a queue from a different IO engine.
  This randomizes both the assignment of the event queues to workers and the order of event execution.
  It is possible that multiple workers would "pump" events from the same queue, while other queues are neglected (and keep growing if events are arriving).
  A queue that is overshared may cause contentions, spinning/sleeping of workers.

• the event queue is basically a memory cache with no upper bounds. We do not know how big the event queue can get if the enqueuing outruns dequeuing for some nontrivial time.
  We do not report the size of this queue in the ThreadPool Queue Length or any other counter even though these are technically threadpool workitems.

=== What we do instead in this PR:
At the high level instead of relying on a queue to reduce the number of global enqueues (temporal batching), we explicitly combine multiple events into batches of predictable and bounded size and enqueue entire batches to the global queue.

Details:

• IO engine fills actual event workitems (in IThreadPoolWorkItem sense) with data.

• The workitems are reused via a pool that has an upper bound.
  (in an unlikely case that the limit is reached we will allocate/GC the workitems).

• To avoid stressing the global queues, the workitems are packed into balanced binary trees, so that we could submit the entire batch for execution in one enqueue.

• Worker threads, upon executing the parent, place the children into the local queue.
  The current worker is likely still the best worker to execute the children, but if other workers need work they can steal whole subtrees thus divide-and-conquering the remaining work.

• as a general approach if execution of an event results in more than one task, we place the additional tasks into the local queue - to relieve the stress on the global queue, improve the locality of execution and statistically reduce the max workqueue lengths.

• the size of a batch is bounded to make sure that large batches do not impact p99 latency.

=== Perf diffs:

JSON benchmarks

 x64 / HIGH load (56 cores, load 4096 connections, load threads=64)
- base RPS 2,528,080 p50 1.47 ms p99 3.79 ms+ new RPS 2,580,722 p50 1.50 ms p99 3.13 ms
+2.1% +2.0% -17.4%
x64 / LOW load (56 cores, load 512 connections)
- base RPS 2,141,591 p50 0.21 ms p99 0.57 ms+ new RPS 2,177,068 p50 0.21 ms p99 0.59 ms
+1.7% 0.0% +3.5%
arm64 / HIGH load (96 cores, load 4096 connections, load threads=64)
- base RPS 3,715,921 p50 0.57 ms p99 7.30 ms+ new RPS 3,696,351 p50 0.56 ms p99 7.01 ms
-0.5% -1.8% -4.0%
arm64 / LOW load (96 cores, load 256 connections)
- base RPS 2,064,045 p50 0.25 ms p99 0.78 ms+ new RPS 2,149,487 p50 0.25 ms p99 0.44 ms
+4.1% 0.0% -43.6%

The change appears to erase most of the gap with net10 on JSON benchmark in high core configuration, thus:
Fixes: #127484

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR changes how socket / IO completion events are dispatched to the thread pool, replacing the prior “queue + pumping work item” pattern with pooled per-event work items that are submitted in batches via a balanced binary tree to reduce global-queue pressure and bound memory growth.

Changes:

• Remove the Windows-only ThreadPoolTypedWorkItemQueue sub-dispatcher from ThreadPoolWorkQueue.
• Windows IOCP: pool IOCompletionPoller.Event instances and batch-submit completions as a balanced tree, fanning out to local queues as nodes execute.
• Unix sockets: pool SocketIOEvent instances and similarly batch-submit async socket events as a balanced tree; adjust some preferLocal scheduling.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs	Removes the Windows-only typed work item queue implementation previously used for IO sub-dispatch.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs	Introduces pooled Event work items and balanced-tree batching for IOCP completions; changes queueing behavior.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs	Reworks async socket event dispatch to use pooled SocketIOEvent work items and balanced-tree batching.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs	Switches some thread-pool queueing to preferLocal: true for async operation processing/cancellation callbacks.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• Using ConcurrentQueue<T>.Count in the hot path (SocketIOEvent.Execute) can be quite expensive under contention (Count is not O(1) for ConcurrentQueue<T>). Since this runs per completion, it risks regressing throughput and adding cross-thread cache contention. Consider tracking pool size with an explicit int counter (Interlocked increment/decrement on enqueue/dequeue) instead of calling Count here.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• Using ConcurrentQueue<T>.Count in Event.Execute is a potentially expensive operation under contention (Count is not O(1) for ConcurrentQueue<T>). Since this executes per IO completion, it can add avoidable overhead. Consider tracking pool size with an explicit Interlocked counter on borrow/return instead of querying Count here.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it for every completion work item defeats some of the intended perf/throughput wins.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it on every async socket event adds overhead on the hot path.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:102

• The comment above _eventQueue says it’s a queue of events generated by EventLoop, but in this revision _eventQueue is used as a pool of reusable SocketIOEvent instances (see RentEvent and SocketIOEvent.Execute). Updating the comment would prevent future confusion about its semantics and why it’s bounded.

 //
// Queue of events generated by EventLoop() that would be processed by the thread pool
//
private readonly ConcurrentQueue<SocketIOEvent> _eventQueue = new ConcurrentQueue<SocketIOEvent>();

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:512

• Event pooling uses ConcurrentQueue.Count on every completion to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock (see ConcurrentQueue.cs), so calling it in this hot path can add contention/latency and offset the intended allocation savings. Consider using an Interlocked-based approximate pool size counter (increment on Enqueue, decrement on Dequeue) instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:527

• SocketIOEvent pooling uses ConcurrentQueue.Count on every event execution to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock, so this can be a measurable hot-path cost under high IO rates. Consider tracking pool size via an Interlocked counter (increment on Enqueue, decrement on RentEvent dequeue success) instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:509

• Using ConcurrentQueue.Count on every IO completion to enforce the pool bound is potentially expensive. ConcurrentQueue.Count can spin and may take _crossSegmentLock when there are multiple segments (see System.Collections.Concurrent.ConcurrentQueue.Count implementation), which can become a noticeable overhead at high IO rates. Consider tracking pool size with an Interlocked counter (increment on Enqueue, decrement on successful TryDequeue) to keep the bound check O(1) without extra locking.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:533

• SocketIOEvent.Execute() uses ConcurrentQueue.Count to enforce the pool bound. ConcurrentQueue.Count can spin and may take the cross-segment lock when multiple segments exist, so doing this per event can add measurable overhead under heavy IO. Consider maintaining an Interlocked pool-size counter instead of calling Count in the hot path.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue<T>.Count can take _crossSegmentLock (and spin/retry) when the queue has multiple segments, so calling _pool.Count on every completion is a potentially expensive hot-path operation and undermines the goal of reducing overhead. Consider tracking the pool size with an int updated via Interlocked on enqueue/dequeue (best-effort is fine) and use that value for the MaxEventPoolCount check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• _pool.Count is queried for every SocketIOEvent execution. ConcurrentQueue<T>.Count is not a cheap counter; it may spin and can take _crossSegmentLock when multiple segments exist, so this can become a measurable overhead under high event rates. Consider maintaining an int pool size updated via Interlocked on enqueue/dequeue and using that for the MaxEventPoolCount gate instead of Count.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[VSadov]

@MihuBot benchmark System.Threading

[VSadov]

@MihuBot benchmark System.Buffers

[MihuBot]

System.Threading.Tests.Perf_Volatile

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Write_double	Main	0.9338 ns	0.0040 ns	1.00	-	NA
Write_double	PR	0.9317 ns	0.0029 ns	1.00	-	NA
Read_double	Main	0.9485 ns	0.0045 ns	1.00	-	NA
Read_double	PR	0.9459 ns	0.0064 ns	1.00	-	NA

System.Threading.Tests.Perf_Timer

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ShortScheduleAndDispose	Main	74.99 ns	0.395 ns	1.00	120 B	1.00
ShortScheduleAndDispose	PR	75.45 ns	0.697 ns	1.01	120 B	1.00
LongScheduleAndDispose	Main	75.44 ns	0.651 ns	1.00	120 B	1.00
LongScheduleAndDispose	PR	75.34 ns	0.673 ns	1.00	120 B	1.00
ScheduleManyThenDisposeMany	Main	223,379,838.13 ns	1,965,673.532 ns	1.00	144001328 B	1.00
ScheduleManyThenDisposeMany	PR	223,129,600.73 ns	2,591,171.964 ns	1.00	144001328 B	1.00
ShortScheduleAndDisposeWithFiringTimers	Main	80.28 ns	1.599 ns	1.00	144 B	1.00
ShortScheduleAndDisposeWithFiringTimers	PR	80.46 ns	1.515 ns	1.00	144 B	1.00
SynchronousContention	Main	1,420,584,665.07 ns	17,411,095.255 ns	1.00	1152000760 B	1.00
SynchronousContention	PR	1,298,023,677.18 ns	25,870,105.978 ns	0.91	1152000760 B	1.00
AsynchronousContention	Main	1,128,918,393.85 ns	36,890,792.880 ns	1.00	1152002232 B	1.00
AsynchronousContention	PR	1,403,692,668.40 ns	41,823,779.338 ns	1.25	1152002232 B	1.00

System.Threading.Tests.Perf_ThreadStatic

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
GetThreadStatic	Main	1.869 ns	0.0084 ns	1.00	-	NA
GetThreadStatic	PR	1.886 ns	0.0068 ns	1.01	-	NA
SetThreadStatic	Main	3.271 ns	0.0107 ns	1.00	-	NA
SetThreadStatic	PR	3.272 ns	0.0150 ns	1.00	-	NA

System.Threading.Tests.Perf_ThreadPool

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1 Gen0=38000.0000

Method	Toolchain	WorkItemsPerCore	Mean	Error	Ratio	Allocated	Alloc Ratio
QueueUserWorkItem_WaitCallback_Throughput	Main	20000000	1.980 s	0.0144 s	1.00	610.35 MB	1.00
QueueUserWorkItem_WaitCallback_Throughput	PR	20000000	1.965 s	0.0112 s	0.99	610.35 MB	1.00

System.Threading.Tests.Perf_Thread

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
CurrentThread	Main	1.895 ns	0.0140 ns	1.00	-	NA
CurrentThread	PR	1.892 ns	0.0078 ns	1.00	-	NA
GetCurrentProcessorId	Main	2.321 ns	0.0074 ns	1.00	-	NA
GetCurrentProcessorId	PR	2.119 ns	0.0111 ns	0.91	-	NA

System.Threading.Tests.Perf_SpinLock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	10.560 ns	0.0062 ns	1.00	-	NA
EnterExit	PR	10.553 ns	0.0124 ns	1.00	-	NA
TryEnterExit	Main	10.564 ns	0.0055 ns	1.00	-	NA
TryEnterExit	PR	10.546 ns	0.0044 ns	1.00	-	NA
TryEnter_Fail	Main	1.236 ns	0.0054 ns	1.00	-	NA
TryEnter_Fail	PR	1.233 ns	0.0050 ns	1.00	-	NA

System.Threading.Tests.Perf_SemaphoreSlim

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReleaseWait	Main	29.63 ns	0.016 ns	1.00	-	NA
ReleaseWait	PR	29.65 ns	0.014 ns	1.00	-	NA
ReleaseWaitAsync	Main	28.25 ns	0.021 ns	1.00	-	NA
ReleaseWaitAsync	PR	28.26 ns	0.011 ns	1.00	-	NA
ReleaseWaitAsync_WithCancellationToken	Main	317.66 ns	20.687 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithCancellationToken	PR	317.60 ns	22.628 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithTimeout	Main	337.80 ns	17.205 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithTimeout	PR	318.12 ns	7.530 ns	0.94	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	Main	361.32 ns	11.905 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	PR	362.21 ns	17.881 ns	1.00	624 B	1.00

System.Threading.Tests.Perf_Monitor

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	13.55 ns	0.008 ns	1.00	-	NA
EnterExit	PR	13.55 ns	0.006 ns	1.00	-	NA
TryEnterExit	Main	13.55 ns	0.009 ns	1.00	-	NA
TryEnterExit	PR	13.54 ns	0.007 ns	1.00	-	NA

System.Threading.Tests.Perf_Lock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReaderWriterLockSlimPerf	Main	13.55 ns	0.008 ns	1.00	-	NA
ReaderWriterLockSlimPerf	PR	13.55 ns	0.034 ns	1.00	-	NA

System.Threading.Tests.Perf_Interlocked

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Increment_int	Main	4.824 ns	0.0021 ns	1.00	-	NA
Increment_int	PR	4.820 ns	0.0040 ns	1.00	-	NA
Decrement_int	Main	4.829 ns	0.0159 ns	1.00	-	NA
Decrement_int	PR	4.819 ns	0.0018 ns	1.00	-	NA
Increment_long	Main	4.818 ns	0.0025 ns	1.00	-	NA
Increment_long	PR	4.820 ns	0.0016 ns	1.00	-	NA
Decrement_long	Main	4.815 ns	0.0020 ns	1.00	-	NA
Decrement_long	PR	4.820 ns	0.0025 ns	1.00	-	NA
Add_int	Main	4.815 ns	0.0016 ns	1.00	-	NA
Add_int	PR	4.816 ns	0.0022 ns	1.00	-	NA
Add_long	Main	4.817 ns	0.0019 ns	1.00	-	NA
Add_long	PR	4.819 ns	0.0019 ns	1.00	-	NA
Exchange_int	Main	4.819 ns	0.0033 ns	1.00	-	NA
Exchange_int	PR	4.819 ns	0.0048 ns	1.00	-	NA
Exchange_long	Main	4.817 ns	0.0020 ns	1.00	-	NA
Exchange_long	PR	4.820 ns	0.0020 ns	1.00	-	NA
CompareExchange_int	Main	4.829 ns	0.0024 ns	1.00	-	NA
CompareExchange_int	PR	4.830 ns	0.0019 ns	1.00	-	NA
CompareExchange_long	Main	4.832 ns	0.0037 ns	1.00	-	NA
CompareExchange_long	PR	4.831 ns	0.0033 ns	1.00	-	NA
CompareExchange_object_Match	Main	5.509 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_Match	PR	5.508 ns	0.0035 ns	1.00	-	NA
CompareExchange_object_NoMatch	Main	5.510 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_NoMatch	PR	5.508 ns	0.0041 ns	1.00	-	NA

System.Threading.Tests.Perf_EventWaitHandle

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Set_Reset	Main	42.75 ns	0.027 ns	1.00	-	NA
Set_Reset	PR	42.72 ns	0.020 ns	1.00	-	NA

System.Threading.Tests.Perf_CancellationToken

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
RegisterAndUnregister_Serial	Main	18.912 ns	0.0493 ns	1.00	-	NA
RegisterAndUnregister_Serial	PR	18.946 ns	0.1112 ns	1.00	-	NA
Cancel	Main	54.448 ns	0.8583 ns	1.00	192 B	1.00
Cancel	PR	53.189 ns	0.3285 ns	0.98	192 B	1.00
CreateLinkedTokenSource1	Main	21.830 ns	0.3112 ns	1.00	64 B	1.00
CreateLinkedTokenSource1	PR	21.034 ns	0.4128 ns	0.96	64 B	1.00
CreateLinkedTokenSource2	Main	38.236 ns	0.4997 ns	1.00	80 B	1.00
CreateLinkedTokenSource2	PR	37.323 ns	0.1491 ns	0.98	80 B	1.00
CreateLinkedTokenSource3	Main	58.207 ns	0.3793 ns	1.00	128 B	1.00
CreateLinkedTokenSource3	PR	58.819 ns	0.3601 ns	1.01	128 B	1.00
CreateTokenDispose	Main	5.448 ns	0.0367 ns	1.00	48 B	1.00
CreateTokenDispose	PR	5.462 ns	0.0467 ns	1.00	48 B	1.00
CreateRegisterDispose	Main	32.044 ns	0.3211 ns	1.00	192 B	1.00
CreateRegisterDispose	PR	31.946 ns	0.3375 ns	1.00	192 B	1.00
CreateManyRegisterDispose	Main	14.507 ns	0.0215 ns	1.00	-	NA
CreateManyRegisterDispose	PR	14.487 ns	0.0178 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	Main	80.629 ns	0.1873 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	PR	81.699 ns	0.1683 ns	1.01	-	NA
CancelAfter	Main	51.286 ns	0.3029 ns	1.00	144 B	1.00
CancelAfter	PR	52.058 ns	1.7330 ns	1.02	144 B	1.00

System.Threading.Tasks.Tests.Perf_AsyncMethods

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EmptyAsyncMethodInvocation	Main	3.731 ns	0.0128 ns	1.00	-	NA
EmptyAsyncMethodInvocation	PR	3.286 ns	0.0038 ns	0.88	-	NA
SingleYieldMethodInvocation	Main	102.221 ns	5.3328 ns	1.00	96 B	1.00
SingleYieldMethodInvocation	PR	100.185 ns	4.8837 ns	0.98	96 B	1.00
Yield	Main	30.483 ns	0.5967 ns	1.00	-	NA
Yield	PR	30.693 ns	1.1908 ns	1.01	-	NA

System.Threading.Tasks.ValueTaskPerfTest

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-UXTJFQ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-WCARJH : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-XVCCJK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HMQJNI : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MaxWarmupIterationCount=10 MinIterationCount=15
MinWarmupIterationCount=2 WarmupCount=-1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Await_FromResult	Main	5.328 ns	0.0110 ns	1.00	-	NA
Await_FromResult	PR	5.446 ns	0.0079 ns	1.02	-	NA
Await_FromCompletedTask	Main	9.748 ns	0.1823 ns	1.00	72 B	1.00
Await_FromCompletedTask	PR	9.318 ns	0.1712 ns	0.96	72 B	1.00
Await_FromCompletedValueTaskSource	Main	15.410 ns	0.2158 ns	1.00	72 B	1.00
Await_FromCompletedValueTaskSource	PR	15.242 ns	0.1697 ns	0.99	72 B	1.00
CreateAndAwait_FromResult	Main	5.281 ns	0.0154 ns	1.00	-	NA
CreateAndAwait_FromResult	PR	5.294 ns	0.0182 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	Main	5.276 ns	0.0160 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	PR	5.312 ns	0.0280 ns	1.01	-	NA
CreateAndAwait_FromCompletedTask	Main	5.774 ns	0.0214 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask	PR	5.914 ns	0.0899 ns	1.02	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	Main	5.817 ns	0.0137 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	PR	6.211 ns	0.0136 ns	1.07	-	NA
CreateAndAwait_FromCompletedValueTaskSource	Main	6.762 ns	0.0108 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource	PR	6.319 ns	0.0094 ns	0.93	-	NA
CreateAndAwait_FromYieldingAsyncMethod	Main	204.260 ns	9.2949 ns	1.00	207 B	1.00
CreateAndAwait_FromYieldingAsyncMethod	PR	212.860 ns	13.1086 ns	1.04	207 B	1.00
CreateAndAwait_FromDelayedTCS	Main	77.672 ns	0.3388 ns	1.00	216 B	1.00
CreateAndAwait_FromDelayedTCS	PR	76.081 ns	0.5506 ns	0.98	216 B	1.00
Copy_PassAsArgumentAndReturn_FromResult	Main	2.842 ns	0.0268 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromResult	PR	2.832 ns	0.0272 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	Main	5.853 ns	0.0244 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	PR	6.085 ns	0.0314 ns	1.04	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	Main	8.025 ns	0.0529 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	PR	7.993 ns	0.0522 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	Main	6.334 ns	0.0582 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	PR	6.310 ns	0.0456 ns	1.00	-	NA

System.Threading.Channels.Tests.UnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	30.37 ns	0.041 ns	1.00	-	NA
TryWriteThenTryRead	PR	30.40 ns	0.034 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	30.35 ns	0.029 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	30.35 ns	0.019 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	49.04 ns	0.016 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	49.30 ns	0.207 ns	1.01	-	NA
PingPong	Main	2,627,902.03 ns	111,019.119 ns	1.00	903 B	1.00
PingPong	PR	2,658,820.31 ns	145,066.288 ns	1.01	901 B	1.00

System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	17.54 ns	0.013 ns	1.00	-	NA
TryWriteThenTryRead	PR	17.54 ns	0.010 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	22.39 ns	0.016 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	22.43 ns	0.025 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	46.94 ns	0.020 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	47.04 ns	0.076 ns	1.00	-	NA
PingPong	Main	2,511,563.26 ns	93,531.184 ns	1.00	901 B	1.00
PingPong	PR	2,627,531.08 ns	129,689.322 ns	1.05	900 B	1.00

System.Threading.Channels.Tests.BoundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	35.91 ns	0.031 ns	1.00	-	NA
TryWriteThenTryRead	PR	35.87 ns	0.019 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	37.57 ns	0.044 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	37.61 ns	0.061 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	47.84 ns	0.043 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	48.03 ns	0.038 ns	1.00	-	NA
PingPong	Main	2,893,666.76 ns	138,789.838 ns	1.00	901 B	1.00
PingPong	PR	2,847,279.72 ns	148,677.365 ns	0.99	901 B	1.00

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/ea54990edbbdbf16145eaa382580240f

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Calling it on every IO completion can become a noticeable CPU cost exactly when the pool is large. Consider enforcing MaxEventPoolCount with a separate Interlocked-updated counter (increment when returning an Event to the pool, decrement when renting) so the hot path avoids Count while still bounding growth.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Checking it on every SocketIOEvent.Execute() adds avoidable overhead on a very hot path and becomes more expensive as the pool grows. Consider tracking an explicit pool size counter (Interlocked) so MaxEventPoolCount can be enforced without calling Count per completion.

 if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[eduardo-vp]

LGTM!

[VSadov]

Thanks!

[VSadov]

To avoid allocating a workitem per every socket/IO event and reduce the number of enqueues to the global queue we use the following pattern:

• Socket/IO engine places the events (a struct) into a concurrent queue, where the storage is naturally reused.
• In order to get the event executed, we post a self-replicating workitem into a global queue and that workitem fetches the events and executes them.
• There is also a heuristic that if the queue runs dry or after some time duration (and in Windows case also in a presence of local workitems) the task stops "pumping" of the events would not starve other workitems.

=== The pattern has some issues that get worse on big core counts:

• The self-replication of the event queue task places copies of itself into the global queue every time a worker starts "pumping" and sees more items in the queue. We must do this for correctness - to make sure that remaining queued events will be eventually picked up even if the current thread blocks.
  This self-requeuing can put a lot of stress on the global queue.
  In a case of assignable queues, the re-queued item ends up in the assignable queue, which are local to a subset of workers, thus may impact p99 latencies.

• When a worker stops dispatching from the event queue (due to time limit, for example) and then picks up an event queue task again, it may be a queue from a different IO engine.
  This randomizes both the assignment of the event queues to workers and the order of event execution.
  It is possible that multiple workers would "pump" events from the same queue, while other queues are neglected (and keep growing if events are arriving).
  A queue that is overshared may cause contentions, spinning/sleeping of workers.

• the event queue is basically a memory cache with no upper bounds. We do not know how big the event queue can get if the enqueuing outruns dequeuing for some nontrivial time.
  We do not report the size of this queue in the ThreadPool Queue Length or any other counter even though these are technically threadpool workitems.

=== What we do instead in this PR:
At the high level instead of relying on a queue to reduce the number of global enqueues (temporal batching), we explicitly combine multiple events into batches of predictable and bounded size and enqueue entire batches to the global queue.

Details:

• IO engine fills actual event workitems (in IThreadPoolWorkItem sense) with data.

• The workitems are reused via a pool that has an upper bound.
  (in an unlikely case that the limit is reached we will allocate/GC the workitems).

• To avoid stressing the global queues, the workitems are packed into balanced binary trees, so that we could submit the entire batch for execution in one enqueue.

• Worker threads, upon executing the parent, place the children into the local queue.
  The current worker is likely still the best worker to execute the children, but if other workers need work they can steal whole subtrees thus divide-and-conquering the remaining work.

• as a general approach if execution of an event results in more than one task, we place the additional tasks into the local queue - to relieve the stress on the global queue, improve the locality of execution and statistically reduce the max workqueue lengths.

• the size of a batch is bounded to make sure that large batches do not impact p99 latency.

=== Perf diffs:

JSON benchmarks

 x64 / HIGH load (56 cores, load 4096 connections, load threads=64)
- base RPS 2,528,080 p50 1.47 ms p99 3.79 ms+ new RPS 2,580,722 p50 1.50 ms p99 3.13 ms
+2.1% +2.0% -17.4%
x64 / LOW load (56 cores, load 512 connections)
- base RPS 2,141,591 p50 0.21 ms p99 0.57 ms+ new RPS 2,177,068 p50 0.21 ms p99 0.59 ms
+1.7% 0.0% +3.5%
arm64 / HIGH load (96 cores, load 4096 connections, load threads=64)
- base RPS 3,715,921 p50 0.57 ms p99 7.30 ms+ new RPS 3,696,351 p50 0.56 ms p99 7.01 ms
-0.5% -1.8% -4.0%
arm64 / LOW load (96 cores, load 256 connections)
- base RPS 2,064,045 p50 0.25 ms p99 0.78 ms+ new RPS 2,149,487 p50 0.25 ms p99 0.44 ms
+4.1% 0.0% -43.6%

The change appears to erase most of the gap with net10 on JSON benchmark in high core configuration, thus:
Fixes: #127484

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR changes how socket / IO completion events are dispatched to the thread pool, replacing the prior “queue + pumping work item” pattern with pooled per-event work items that are submitted in batches via a balanced binary tree to reduce global-queue pressure and bound memory growth.

Changes:

• Remove the Windows-only ThreadPoolTypedWorkItemQueue sub-dispatcher from ThreadPoolWorkQueue.
• Windows IOCP: pool IOCompletionPoller.Event instances and batch-submit completions as a balanced tree, fanning out to local queues as nodes execute.
• Unix sockets: pool SocketIOEvent instances and similarly batch-submit async socket events as a balanced tree; adjust some preferLocal scheduling.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs	Removes the Windows-only typed work item queue implementation previously used for IO sub-dispatch.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs	Introduces pooled Event work items and balanced-tree batching for IOCP completions; changes queueing behavior.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs	Reworks async socket event dispatch to use pooled SocketIOEvent work items and balanced-tree batching.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs	Switches some thread-pool queueing to preferLocal: true for async operation processing/cancellation callbacks.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• Using ConcurrentQueue<T>.Count in the hot path (SocketIOEvent.Execute) can be quite expensive under contention (Count is not O(1) for ConcurrentQueue<T>). Since this runs per completion, it risks regressing throughput and adding cross-thread cache contention. Consider tracking pool size with an explicit int counter (Interlocked increment/decrement on enqueue/dequeue) instead of calling Count here.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• Using ConcurrentQueue<T>.Count in Event.Execute is a potentially expensive operation under contention (Count is not O(1) for ConcurrentQueue<T>). Since this executes per IO completion, it can add avoidable overhead. Consider tracking pool size with an explicit Interlocked counter on borrow/return instead of querying Count here.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it for every completion work item defeats some of the intended perf/throughput wins.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it on every async socket event adds overhead on the hot path.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:102

• The comment above _eventQueue says it’s a queue of events generated by EventLoop, but in this revision _eventQueue is used as a pool of reusable SocketIOEvent instances (see RentEvent and SocketIOEvent.Execute). Updating the comment would prevent future confusion about its semantics and why it’s bounded.

 //
// Queue of events generated by EventLoop() that would be processed by the thread pool
//
private readonly ConcurrentQueue<SocketIOEvent> _eventQueue = new ConcurrentQueue<SocketIOEvent>();

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:512

• Event pooling uses ConcurrentQueue.Count on every completion to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock (see ConcurrentQueue.cs), so calling it in this hot path can add contention/latency and offset the intended allocation savings. Consider using an Interlocked-based approximate pool size counter (increment on Enqueue, decrement on Dequeue) instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:527

• SocketIOEvent pooling uses ConcurrentQueue.Count on every event execution to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock, so this can be a measurable hot-path cost under high IO rates. Consider tracking pool size via an Interlocked counter (increment on Enqueue, decrement on RentEvent dequeue success) instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:509

• Using ConcurrentQueue.Count on every IO completion to enforce the pool bound is potentially expensive. ConcurrentQueue.Count can spin and may take _crossSegmentLock when there are multiple segments (see System.Collections.Concurrent.ConcurrentQueue.Count implementation), which can become a noticeable overhead at high IO rates. Consider tracking pool size with an Interlocked counter (increment on Enqueue, decrement on successful TryDequeue) to keep the bound check O(1) without extra locking.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:533

• SocketIOEvent.Execute() uses ConcurrentQueue.Count to enforce the pool bound. ConcurrentQueue.Count can spin and may take the cross-segment lock when multiple segments exist, so doing this per event can add measurable overhead under heavy IO. Consider maintaining an Interlocked pool-size counter instead of calling Count in the hot path.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue<T>.Count can take _crossSegmentLock (and spin/retry) when the queue has multiple segments, so calling _pool.Count on every completion is a potentially expensive hot-path operation and undermines the goal of reducing overhead. Consider tracking the pool size with an int updated via Interlocked on enqueue/dequeue (best-effort is fine) and use that value for the MaxEventPoolCount check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• _pool.Count is queried for every SocketIOEvent execution. ConcurrentQueue<T>.Count is not a cheap counter; it may spin and can take _crossSegmentLock when multiple segments exist, so this can become a measurable overhead under high event rates. Consider maintaining an int pool size updated via Interlocked on enqueue/dequeue and using that for the MaxEventPoolCount gate instead of Count.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[VSadov]

@MihuBot benchmark System.Threading

[VSadov]

@MihuBot benchmark System.Buffers

[MihuBot]

System.Threading.Tests.Perf_Volatile

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Write_double	Main	0.9338 ns	0.0040 ns	1.00	-	NA
Write_double	PR	0.9317 ns	0.0029 ns	1.00	-	NA
Read_double	Main	0.9485 ns	0.0045 ns	1.00	-	NA
Read_double	PR	0.9459 ns	0.0064 ns	1.00	-	NA

System.Threading.Tests.Perf_Timer

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ShortScheduleAndDispose	Main	74.99 ns	0.395 ns	1.00	120 B	1.00
ShortScheduleAndDispose	PR	75.45 ns	0.697 ns	1.01	120 B	1.00
LongScheduleAndDispose	Main	75.44 ns	0.651 ns	1.00	120 B	1.00
LongScheduleAndDispose	PR	75.34 ns	0.673 ns	1.00	120 B	1.00
ScheduleManyThenDisposeMany	Main	223,379,838.13 ns	1,965,673.532 ns	1.00	144001328 B	1.00
ScheduleManyThenDisposeMany	PR	223,129,600.73 ns	2,591,171.964 ns	1.00	144001328 B	1.00
ShortScheduleAndDisposeWithFiringTimers	Main	80.28 ns	1.599 ns	1.00	144 B	1.00
ShortScheduleAndDisposeWithFiringTimers	PR	80.46 ns	1.515 ns	1.00	144 B	1.00
SynchronousContention	Main	1,420,584,665.07 ns	17,411,095.255 ns	1.00	1152000760 B	1.00
SynchronousContention	PR	1,298,023,677.18 ns	25,870,105.978 ns	0.91	1152000760 B	1.00
AsynchronousContention	Main	1,128,918,393.85 ns	36,890,792.880 ns	1.00	1152002232 B	1.00
AsynchronousContention	PR	1,403,692,668.40 ns	41,823,779.338 ns	1.25	1152002232 B	1.00

System.Threading.Tests.Perf_ThreadStatic

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
GetThreadStatic	Main	1.869 ns	0.0084 ns	1.00	-	NA
GetThreadStatic	PR	1.886 ns	0.0068 ns	1.01	-	NA
SetThreadStatic	Main	3.271 ns	0.0107 ns	1.00	-	NA
SetThreadStatic	PR	3.272 ns	0.0150 ns	1.00	-	NA

System.Threading.Tests.Perf_ThreadPool

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1 Gen0=38000.0000

Method	Toolchain	WorkItemsPerCore	Mean	Error	Ratio	Allocated	Alloc Ratio
QueueUserWorkItem_WaitCallback_Throughput	Main	20000000	1.980 s	0.0144 s	1.00	610.35 MB	1.00
QueueUserWorkItem_WaitCallback_Throughput	PR	20000000	1.965 s	0.0112 s	0.99	610.35 MB	1.00

System.Threading.Tests.Perf_Thread

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
CurrentThread	Main	1.895 ns	0.0140 ns	1.00	-	NA
CurrentThread	PR	1.892 ns	0.0078 ns	1.00	-	NA
GetCurrentProcessorId	Main	2.321 ns	0.0074 ns	1.00	-	NA
GetCurrentProcessorId	PR	2.119 ns	0.0111 ns	0.91	-	NA

System.Threading.Tests.Perf_SpinLock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	10.560 ns	0.0062 ns	1.00	-	NA
EnterExit	PR	10.553 ns	0.0124 ns	1.00	-	NA
TryEnterExit	Main	10.564 ns	0.0055 ns	1.00	-	NA
TryEnterExit	PR	10.546 ns	0.0044 ns	1.00	-	NA
TryEnter_Fail	Main	1.236 ns	0.0054 ns	1.00	-	NA
TryEnter_Fail	PR	1.233 ns	0.0050 ns	1.00	-	NA

System.Threading.Tests.Perf_SemaphoreSlim

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReleaseWait	Main	29.63 ns	0.016 ns	1.00	-	NA
ReleaseWait	PR	29.65 ns	0.014 ns	1.00	-	NA
ReleaseWaitAsync	Main	28.25 ns	0.021 ns	1.00	-	NA
ReleaseWaitAsync	PR	28.26 ns	0.011 ns	1.00	-	NA
ReleaseWaitAsync_WithCancellationToken	Main	317.66 ns	20.687 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithCancellationToken	PR	317.60 ns	22.628 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithTimeout	Main	337.80 ns	17.205 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithTimeout	PR	318.12 ns	7.530 ns	0.94	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	Main	361.32 ns	11.905 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	PR	362.21 ns	17.881 ns	1.00	624 B	1.00

System.Threading.Tests.Perf_Monitor

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	13.55 ns	0.008 ns	1.00	-	NA
EnterExit	PR	13.55 ns	0.006 ns	1.00	-	NA
TryEnterExit	Main	13.55 ns	0.009 ns	1.00	-	NA
TryEnterExit	PR	13.54 ns	0.007 ns	1.00	-	NA

System.Threading.Tests.Perf_Lock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReaderWriterLockSlimPerf	Main	13.55 ns	0.008 ns	1.00	-	NA
ReaderWriterLockSlimPerf	PR	13.55 ns	0.034 ns	1.00	-	NA

System.Threading.Tests.Perf_Interlocked

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Increment_int	Main	4.824 ns	0.0021 ns	1.00	-	NA
Increment_int	PR	4.820 ns	0.0040 ns	1.00	-	NA
Decrement_int	Main	4.829 ns	0.0159 ns	1.00	-	NA
Decrement_int	PR	4.819 ns	0.0018 ns	1.00	-	NA
Increment_long	Main	4.818 ns	0.0025 ns	1.00	-	NA
Increment_long	PR	4.820 ns	0.0016 ns	1.00	-	NA
Decrement_long	Main	4.815 ns	0.0020 ns	1.00	-	NA
Decrement_long	PR	4.820 ns	0.0025 ns	1.00	-	NA
Add_int	Main	4.815 ns	0.0016 ns	1.00	-	NA
Add_int	PR	4.816 ns	0.0022 ns	1.00	-	NA
Add_long	Main	4.817 ns	0.0019 ns	1.00	-	NA
Add_long	PR	4.819 ns	0.0019 ns	1.00	-	NA
Exchange_int	Main	4.819 ns	0.0033 ns	1.00	-	NA
Exchange_int	PR	4.819 ns	0.0048 ns	1.00	-	NA
Exchange_long	Main	4.817 ns	0.0020 ns	1.00	-	NA
Exchange_long	PR	4.820 ns	0.0020 ns	1.00	-	NA
CompareExchange_int	Main	4.829 ns	0.0024 ns	1.00	-	NA
CompareExchange_int	PR	4.830 ns	0.0019 ns	1.00	-	NA
CompareExchange_long	Main	4.832 ns	0.0037 ns	1.00	-	NA
CompareExchange_long	PR	4.831 ns	0.0033 ns	1.00	-	NA
CompareExchange_object_Match	Main	5.509 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_Match	PR	5.508 ns	0.0035 ns	1.00	-	NA
CompareExchange_object_NoMatch	Main	5.510 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_NoMatch	PR	5.508 ns	0.0041 ns	1.00	-	NA

System.Threading.Tests.Perf_EventWaitHandle

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Set_Reset	Main	42.75 ns	0.027 ns	1.00	-	NA
Set_Reset	PR	42.72 ns	0.020 ns	1.00	-	NA

System.Threading.Tests.Perf_CancellationToken

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
RegisterAndUnregister_Serial	Main	18.912 ns	0.0493 ns	1.00	-	NA
RegisterAndUnregister_Serial	PR	18.946 ns	0.1112 ns	1.00	-	NA
Cancel	Main	54.448 ns	0.8583 ns	1.00	192 B	1.00
Cancel	PR	53.189 ns	0.3285 ns	0.98	192 B	1.00
CreateLinkedTokenSource1	Main	21.830 ns	0.3112 ns	1.00	64 B	1.00
CreateLinkedTokenSource1	PR	21.034 ns	0.4128 ns	0.96	64 B	1.00
CreateLinkedTokenSource2	Main	38.236 ns	0.4997 ns	1.00	80 B	1.00
CreateLinkedTokenSource2	PR	37.323 ns	0.1491 ns	0.98	80 B	1.00
CreateLinkedTokenSource3	Main	58.207 ns	0.3793 ns	1.00	128 B	1.00
CreateLinkedTokenSource3	PR	58.819 ns	0.3601 ns	1.01	128 B	1.00
CreateTokenDispose	Main	5.448 ns	0.0367 ns	1.00	48 B	1.00
CreateTokenDispose	PR	5.462 ns	0.0467 ns	1.00	48 B	1.00
CreateRegisterDispose	Main	32.044 ns	0.3211 ns	1.00	192 B	1.00
CreateRegisterDispose	PR	31.946 ns	0.3375 ns	1.00	192 B	1.00
CreateManyRegisterDispose	Main	14.507 ns	0.0215 ns	1.00	-	NA
CreateManyRegisterDispose	PR	14.487 ns	0.0178 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	Main	80.629 ns	0.1873 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	PR	81.699 ns	0.1683 ns	1.01	-	NA
CancelAfter	Main	51.286 ns	0.3029 ns	1.00	144 B	1.00
CancelAfter	PR	52.058 ns	1.7330 ns	1.02	144 B	1.00

System.Threading.Tasks.Tests.Perf_AsyncMethods

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EmptyAsyncMethodInvocation	Main	3.731 ns	0.0128 ns	1.00	-	NA
EmptyAsyncMethodInvocation	PR	3.286 ns	0.0038 ns	0.88	-	NA
SingleYieldMethodInvocation	Main	102.221 ns	5.3328 ns	1.00	96 B	1.00
SingleYieldMethodInvocation	PR	100.185 ns	4.8837 ns	0.98	96 B	1.00
Yield	Main	30.483 ns	0.5967 ns	1.00	-	NA
Yield	PR	30.693 ns	1.1908 ns	1.01	-	NA

System.Threading.Tasks.ValueTaskPerfTest

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-UXTJFQ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-WCARJH : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-XVCCJK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HMQJNI : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MaxWarmupIterationCount=10 MinIterationCount=15
MinWarmupIterationCount=2 WarmupCount=-1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Await_FromResult	Main	5.328 ns	0.0110 ns	1.00	-	NA
Await_FromResult	PR	5.446 ns	0.0079 ns	1.02	-	NA
Await_FromCompletedTask	Main	9.748 ns	0.1823 ns	1.00	72 B	1.00
Await_FromCompletedTask	PR	9.318 ns	0.1712 ns	0.96	72 B	1.00
Await_FromCompletedValueTaskSource	Main	15.410 ns	0.2158 ns	1.00	72 B	1.00
Await_FromCompletedValueTaskSource	PR	15.242 ns	0.1697 ns	0.99	72 B	1.00
CreateAndAwait_FromResult	Main	5.281 ns	0.0154 ns	1.00	-	NA
CreateAndAwait_FromResult	PR	5.294 ns	0.0182 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	Main	5.276 ns	0.0160 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	PR	5.312 ns	0.0280 ns	1.01	-	NA
CreateAndAwait_FromCompletedTask	Main	5.774 ns	0.0214 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask	PR	5.914 ns	0.0899 ns	1.02	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	Main	5.817 ns	0.0137 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	PR	6.211 ns	0.0136 ns	1.07	-	NA
CreateAndAwait_FromCompletedValueTaskSource	Main	6.762 ns	0.0108 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource	PR	6.319 ns	0.0094 ns	0.93	-	NA
CreateAndAwait_FromYieldingAsyncMethod	Main	204.260 ns	9.2949 ns	1.00	207 B	1.00
CreateAndAwait_FromYieldingAsyncMethod	PR	212.860 ns	13.1086 ns	1.04	207 B	1.00
CreateAndAwait_FromDelayedTCS	Main	77.672 ns	0.3388 ns	1.00	216 B	1.00
CreateAndAwait_FromDelayedTCS	PR	76.081 ns	0.5506 ns	0.98	216 B	1.00
Copy_PassAsArgumentAndReturn_FromResult	Main	2.842 ns	0.0268 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromResult	PR	2.832 ns	0.0272 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	Main	5.853 ns	0.0244 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	PR	6.085 ns	0.0314 ns	1.04	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	Main	8.025 ns	0.0529 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	PR	7.993 ns	0.0522 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	Main	6.334 ns	0.0582 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	PR	6.310 ns	0.0456 ns	1.00	-	NA

System.Threading.Channels.Tests.UnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	30.37 ns	0.041 ns	1.00	-	NA
TryWriteThenTryRead	PR	30.40 ns	0.034 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	30.35 ns	0.029 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	30.35 ns	0.019 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	49.04 ns	0.016 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	49.30 ns	0.207 ns	1.01	-	NA
PingPong	Main	2,627,902.03 ns	111,019.119 ns	1.00	903 B	1.00
PingPong	PR	2,658,820.31 ns	145,066.288 ns	1.01	901 B	1.00

System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	17.54 ns	0.013 ns	1.00	-	NA
TryWriteThenTryRead	PR	17.54 ns	0.010 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	22.39 ns	0.016 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	22.43 ns	0.025 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	46.94 ns	0.020 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	47.04 ns	0.076 ns	1.00	-	NA
PingPong	Main	2,511,563.26 ns	93,531.184 ns	1.00	901 B	1.00
PingPong	PR	2,627,531.08 ns	129,689.322 ns	1.05	900 B	1.00

System.Threading.Channels.Tests.BoundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	35.91 ns	0.031 ns	1.00	-	NA
TryWriteThenTryRead	PR	35.87 ns	0.019 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	37.57 ns	0.044 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	37.61 ns	0.061 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	47.84 ns	0.043 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	48.03 ns	0.038 ns	1.00	-	NA
PingPong	Main	2,893,666.76 ns	138,789.838 ns	1.00	901 B	1.00
PingPong	PR	2,847,279.72 ns	148,677.365 ns	0.99	901 B	1.00

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/ea54990edbbdbf16145eaa382580240f

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Calling it on every IO completion can become a noticeable CPU cost exactly when the pool is large. Consider enforcing MaxEventPoolCount with a separate Interlocked-updated counter (increment when returning an Event to the pool, decrement when renting) so the hot path avoids Count while still bounding growth.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Checking it on every SocketIOEvent.Execute() adds avoidable overhead on a very hot path and becomes more expensive as the pool grows. Consider tracking an explicit pool size counter (Interlocked) so MaxEventPoolCount can be enforced without calling Count per completion.

 if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[eduardo-vp]

LGTM!

[VSadov]

Thanks!

[VSadov]

To avoid allocating a workitem per every socket/IO event and reduce the number of enqueues to the global queue we use the following pattern:

• Socket/IO engine places the events (a struct) into a concurrent queue, where the storage is naturally reused.
• In order to get the event executed, we post a self-replicating workitem into a global queue and that workitem fetches the events and executes them.
• There is also a heuristic that if the queue runs dry or after some time duration (and in Windows case also in a presence of local workitems) the task stops "pumping" of the events would not starve other workitems.

=== The pattern has some issues that get worse on big core counts:

• The self-replication of the event queue task places copies of itself into the global queue every time a worker starts "pumping" and sees more items in the queue. We must do this for correctness - to make sure that remaining queued events will be eventually picked up even if the current thread blocks.
  This self-requeuing can put a lot of stress on the global queue.
  In a case of assignable queues, the re-queued item ends up in the assignable queue, which are local to a subset of workers, thus may impact p99 latencies.

• When a worker stops dispatching from the event queue (due to time limit, for example) and then picks up an event queue task again, it may be a queue from a different IO engine.
  This randomizes both the assignment of the event queues to workers and the order of event execution.
  It is possible that multiple workers would "pump" events from the same queue, while other queues are neglected (and keep growing if events are arriving).
  A queue that is overshared may cause contentions, spinning/sleeping of workers.

• the event queue is basically a memory cache with no upper bounds. We do not know how big the event queue can get if the enqueuing outruns dequeuing for some nontrivial time.
  We do not report the size of this queue in the ThreadPool Queue Length or any other counter even though these are technically threadpool workitems.

=== What we do instead in this PR:
At the high level instead of relying on a queue to reduce the number of global enqueues (temporal batching), we explicitly combine multiple events into batches of predictable and bounded size and enqueue entire batches to the global queue.

Details:

• IO engine fills actual event workitems (in IThreadPoolWorkItem sense) with data.

• The workitems are reused via a pool that has an upper bound.
  (in an unlikely case that the limit is reached we will allocate/GC the workitems).

• To avoid stressing the global queues, the workitems are packed into balanced binary trees, so that we could submit the entire batch for execution in one enqueue.

• Worker threads, upon executing the parent, place the children into the local queue.
  The current worker is likely still the best worker to execute the children, but if other workers need work they can steal whole subtrees thus divide-and-conquering the remaining work.

• as a general approach if execution of an event results in more than one task, we place the additional tasks into the local queue - to relieve the stress on the global queue, improve the locality of execution and statistically reduce the max workqueue lengths.

• the size of a batch is bounded to make sure that large batches do not impact p99 latency.

=== Perf diffs:

JSON benchmarks

 x64 / HIGH load (56 cores, load 4096 connections, load threads=64)
- base RPS 2,528,080 p50 1.47 ms p99 3.79 ms+ new RPS 2,580,722 p50 1.50 ms p99 3.13 ms
+2.1% +2.0% -17.4%
x64 / LOW load (56 cores, load 512 connections)
- base RPS 2,141,591 p50 0.21 ms p99 0.57 ms+ new RPS 2,177,068 p50 0.21 ms p99 0.59 ms
+1.7% 0.0% +3.5%
arm64 / HIGH load (96 cores, load 4096 connections, load threads=64)
- base RPS 3,715,921 p50 0.57 ms p99 7.30 ms+ new RPS 3,696,351 p50 0.56 ms p99 7.01 ms
-0.5% -1.8% -4.0%
arm64 / LOW load (96 cores, load 256 connections)
- base RPS 2,064,045 p50 0.25 ms p99 0.78 ms+ new RPS 2,149,487 p50 0.25 ms p99 0.44 ms
+4.1% 0.0% -43.6%

The change appears to erase most of the gap with net10 on JSON benchmark in high core configuration, thus:
Fixes: #127484

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR changes how socket / IO completion events are dispatched to the thread pool, replacing the prior “queue + pumping work item” pattern with pooled per-event work items that are submitted in batches via a balanced binary tree to reduce global-queue pressure and bound memory growth.

Changes:

• Remove the Windows-only ThreadPoolTypedWorkItemQueue sub-dispatcher from ThreadPoolWorkQueue.
• Windows IOCP: pool IOCompletionPoller.Event instances and batch-submit completions as a balanced tree, fanning out to local queues as nodes execute.
• Unix sockets: pool SocketIOEvent instances and similarly batch-submit async socket events as a balanced tree; adjust some preferLocal scheduling.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs	Removes the Windows-only typed work item queue implementation previously used for IO sub-dispatch.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs	Introduces pooled Event work items and balanced-tree batching for IOCP completions; changes queueing behavior.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs	Reworks async socket event dispatch to use pooled SocketIOEvent work items and balanced-tree batching.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs	Switches some thread-pool queueing to preferLocal: true for async operation processing/cancellation callbacks.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• Using ConcurrentQueue<T>.Count in the hot path (SocketIOEvent.Execute) can be quite expensive under contention (Count is not O(1) for ConcurrentQueue<T>). Since this runs per completion, it risks regressing throughput and adding cross-thread cache contention. Consider tracking pool size with an explicit int counter (Interlocked increment/decrement on enqueue/dequeue) instead of calling Count here.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• Using ConcurrentQueue<T>.Count in Event.Execute is a potentially expensive operation under contention (Count is not O(1) for ConcurrentQueue<T>). Since this executes per IO completion, it can add avoidable overhead. Consider tracking pool size with an explicit Interlocked counter on borrow/return instead of querying Count here.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it for every completion work item defeats some of the intended perf/throughput wins.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it on every async socket event adds overhead on the hot path.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:102

• The comment above _eventQueue says it’s a queue of events generated by EventLoop, but in this revision _eventQueue is used as a pool of reusable SocketIOEvent instances (see RentEvent and SocketIOEvent.Execute). Updating the comment would prevent future confusion about its semantics and why it’s bounded.

 //
// Queue of events generated by EventLoop() that would be processed by the thread pool
//
private readonly ConcurrentQueue<SocketIOEvent> _eventQueue = new ConcurrentQueue<SocketIOEvent>();

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:512

• Event pooling uses ConcurrentQueue.Count on every completion to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock (see ConcurrentQueue.cs), so calling it in this hot path can add contention/latency and offset the intended allocation savings. Consider using an Interlocked-based approximate pool size counter (increment on Enqueue, decrement on Dequeue) instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:527

• SocketIOEvent pooling uses ConcurrentQueue.Count on every event execution to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock, so this can be a measurable hot-path cost under high IO rates. Consider tracking pool size via an Interlocked counter (increment on Enqueue, decrement on RentEvent dequeue success) instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:509

• Using ConcurrentQueue.Count on every IO completion to enforce the pool bound is potentially expensive. ConcurrentQueue.Count can spin and may take _crossSegmentLock when there are multiple segments (see System.Collections.Concurrent.ConcurrentQueue.Count implementation), which can become a noticeable overhead at high IO rates. Consider tracking pool size with an Interlocked counter (increment on Enqueue, decrement on successful TryDequeue) to keep the bound check O(1) without extra locking.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:533

• SocketIOEvent.Execute() uses ConcurrentQueue.Count to enforce the pool bound. ConcurrentQueue.Count can spin and may take the cross-segment lock when multiple segments exist, so doing this per event can add measurable overhead under heavy IO. Consider maintaining an Interlocked pool-size counter instead of calling Count in the hot path.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue<T>.Count can take _crossSegmentLock (and spin/retry) when the queue has multiple segments, so calling _pool.Count on every completion is a potentially expensive hot-path operation and undermines the goal of reducing overhead. Consider tracking the pool size with an int updated via Interlocked on enqueue/dequeue (best-effort is fine) and use that value for the MaxEventPoolCount check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• _pool.Count is queried for every SocketIOEvent execution. ConcurrentQueue<T>.Count is not a cheap counter; it may spin and can take _crossSegmentLock when multiple segments exist, so this can become a measurable overhead under high event rates. Consider maintaining an int pool size updated via Interlocked on enqueue/dequeue and using that for the MaxEventPoolCount gate instead of Count.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[VSadov]

@MihuBot benchmark System.Threading

[VSadov]

@MihuBot benchmark System.Buffers

[MihuBot]

System.Threading.Tests.Perf_Volatile

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Write_double	Main	0.9338 ns	0.0040 ns	1.00	-	NA
Write_double	PR	0.9317 ns	0.0029 ns	1.00	-	NA
Read_double	Main	0.9485 ns	0.0045 ns	1.00	-	NA
Read_double	PR	0.9459 ns	0.0064 ns	1.00	-	NA

System.Threading.Tests.Perf_Timer

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ShortScheduleAndDispose	Main	74.99 ns	0.395 ns	1.00	120 B	1.00
ShortScheduleAndDispose	PR	75.45 ns	0.697 ns	1.01	120 B	1.00
LongScheduleAndDispose	Main	75.44 ns	0.651 ns	1.00	120 B	1.00
LongScheduleAndDispose	PR	75.34 ns	0.673 ns	1.00	120 B	1.00
ScheduleManyThenDisposeMany	Main	223,379,838.13 ns	1,965,673.532 ns	1.00	144001328 B	1.00
ScheduleManyThenDisposeMany	PR	223,129,600.73 ns	2,591,171.964 ns	1.00	144001328 B	1.00
ShortScheduleAndDisposeWithFiringTimers	Main	80.28 ns	1.599 ns	1.00	144 B	1.00
ShortScheduleAndDisposeWithFiringTimers	PR	80.46 ns	1.515 ns	1.00	144 B	1.00
SynchronousContention	Main	1,420,584,665.07 ns	17,411,095.255 ns	1.00	1152000760 B	1.00
SynchronousContention	PR	1,298,023,677.18 ns	25,870,105.978 ns	0.91	1152000760 B	1.00
AsynchronousContention	Main	1,128,918,393.85 ns	36,890,792.880 ns	1.00	1152002232 B	1.00
AsynchronousContention	PR	1,403,692,668.40 ns	41,823,779.338 ns	1.25	1152002232 B	1.00

System.Threading.Tests.Perf_ThreadStatic

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
GetThreadStatic	Main	1.869 ns	0.0084 ns	1.00	-	NA
GetThreadStatic	PR	1.886 ns	0.0068 ns	1.01	-	NA
SetThreadStatic	Main	3.271 ns	0.0107 ns	1.00	-	NA
SetThreadStatic	PR	3.272 ns	0.0150 ns	1.00	-	NA

System.Threading.Tests.Perf_ThreadPool

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1 Gen0=38000.0000

Method	Toolchain	WorkItemsPerCore	Mean	Error	Ratio	Allocated	Alloc Ratio
QueueUserWorkItem_WaitCallback_Throughput	Main	20000000	1.980 s	0.0144 s	1.00	610.35 MB	1.00
QueueUserWorkItem_WaitCallback_Throughput	PR	20000000	1.965 s	0.0112 s	0.99	610.35 MB	1.00

System.Threading.Tests.Perf_Thread

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
CurrentThread	Main	1.895 ns	0.0140 ns	1.00	-	NA
CurrentThread	PR	1.892 ns	0.0078 ns	1.00	-	NA
GetCurrentProcessorId	Main	2.321 ns	0.0074 ns	1.00	-	NA
GetCurrentProcessorId	PR	2.119 ns	0.0111 ns	0.91	-	NA

System.Threading.Tests.Perf_SpinLock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	10.560 ns	0.0062 ns	1.00	-	NA
EnterExit	PR	10.553 ns	0.0124 ns	1.00	-	NA
TryEnterExit	Main	10.564 ns	0.0055 ns	1.00	-	NA
TryEnterExit	PR	10.546 ns	0.0044 ns	1.00	-	NA
TryEnter_Fail	Main	1.236 ns	0.0054 ns	1.00	-	NA
TryEnter_Fail	PR	1.233 ns	0.0050 ns	1.00	-	NA

System.Threading.Tests.Perf_SemaphoreSlim

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReleaseWait	Main	29.63 ns	0.016 ns	1.00	-	NA
ReleaseWait	PR	29.65 ns	0.014 ns	1.00	-	NA
ReleaseWaitAsync	Main	28.25 ns	0.021 ns	1.00	-	NA
ReleaseWaitAsync	PR	28.26 ns	0.011 ns	1.00	-	NA
ReleaseWaitAsync_WithCancellationToken	Main	317.66 ns	20.687 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithCancellationToken	PR	317.60 ns	22.628 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithTimeout	Main	337.80 ns	17.205 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithTimeout	PR	318.12 ns	7.530 ns	0.94	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	Main	361.32 ns	11.905 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	PR	362.21 ns	17.881 ns	1.00	624 B	1.00

System.Threading.Tests.Perf_Monitor

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	13.55 ns	0.008 ns	1.00	-	NA
EnterExit	PR	13.55 ns	0.006 ns	1.00	-	NA
TryEnterExit	Main	13.55 ns	0.009 ns	1.00	-	NA
TryEnterExit	PR	13.54 ns	0.007 ns	1.00	-	NA

System.Threading.Tests.Perf_Lock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReaderWriterLockSlimPerf	Main	13.55 ns	0.008 ns	1.00	-	NA
ReaderWriterLockSlimPerf	PR	13.55 ns	0.034 ns	1.00	-	NA

System.Threading.Tests.Perf_Interlocked

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Increment_int	Main	4.824 ns	0.0021 ns	1.00	-	NA
Increment_int	PR	4.820 ns	0.0040 ns	1.00	-	NA
Decrement_int	Main	4.829 ns	0.0159 ns	1.00	-	NA
Decrement_int	PR	4.819 ns	0.0018 ns	1.00	-	NA
Increment_long	Main	4.818 ns	0.0025 ns	1.00	-	NA
Increment_long	PR	4.820 ns	0.0016 ns	1.00	-	NA
Decrement_long	Main	4.815 ns	0.0020 ns	1.00	-	NA
Decrement_long	PR	4.820 ns	0.0025 ns	1.00	-	NA
Add_int	Main	4.815 ns	0.0016 ns	1.00	-	NA
Add_int	PR	4.816 ns	0.0022 ns	1.00	-	NA
Add_long	Main	4.817 ns	0.0019 ns	1.00	-	NA
Add_long	PR	4.819 ns	0.0019 ns	1.00	-	NA
Exchange_int	Main	4.819 ns	0.0033 ns	1.00	-	NA
Exchange_int	PR	4.819 ns	0.0048 ns	1.00	-	NA
Exchange_long	Main	4.817 ns	0.0020 ns	1.00	-	NA
Exchange_long	PR	4.820 ns	0.0020 ns	1.00	-	NA
CompareExchange_int	Main	4.829 ns	0.0024 ns	1.00	-	NA
CompareExchange_int	PR	4.830 ns	0.0019 ns	1.00	-	NA
CompareExchange_long	Main	4.832 ns	0.0037 ns	1.00	-	NA
CompareExchange_long	PR	4.831 ns	0.0033 ns	1.00	-	NA
CompareExchange_object_Match	Main	5.509 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_Match	PR	5.508 ns	0.0035 ns	1.00	-	NA
CompareExchange_object_NoMatch	Main	5.510 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_NoMatch	PR	5.508 ns	0.0041 ns	1.00	-	NA

System.Threading.Tests.Perf_EventWaitHandle

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Set_Reset	Main	42.75 ns	0.027 ns	1.00	-	NA
Set_Reset	PR	42.72 ns	0.020 ns	1.00	-	NA

System.Threading.Tests.Perf_CancellationToken

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
RegisterAndUnregister_Serial	Main	18.912 ns	0.0493 ns	1.00	-	NA
RegisterAndUnregister_Serial	PR	18.946 ns	0.1112 ns	1.00	-	NA
Cancel	Main	54.448 ns	0.8583 ns	1.00	192 B	1.00
Cancel	PR	53.189 ns	0.3285 ns	0.98	192 B	1.00
CreateLinkedTokenSource1	Main	21.830 ns	0.3112 ns	1.00	64 B	1.00
CreateLinkedTokenSource1	PR	21.034 ns	0.4128 ns	0.96	64 B	1.00
CreateLinkedTokenSource2	Main	38.236 ns	0.4997 ns	1.00	80 B	1.00
CreateLinkedTokenSource2	PR	37.323 ns	0.1491 ns	0.98	80 B	1.00
CreateLinkedTokenSource3	Main	58.207 ns	0.3793 ns	1.00	128 B	1.00
CreateLinkedTokenSource3	PR	58.819 ns	0.3601 ns	1.01	128 B	1.00
CreateTokenDispose	Main	5.448 ns	0.0367 ns	1.00	48 B	1.00
CreateTokenDispose	PR	5.462 ns	0.0467 ns	1.00	48 B	1.00
CreateRegisterDispose	Main	32.044 ns	0.3211 ns	1.00	192 B	1.00
CreateRegisterDispose	PR	31.946 ns	0.3375 ns	1.00	192 B	1.00
CreateManyRegisterDispose	Main	14.507 ns	0.0215 ns	1.00	-	NA
CreateManyRegisterDispose	PR	14.487 ns	0.0178 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	Main	80.629 ns	0.1873 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	PR	81.699 ns	0.1683 ns	1.01	-	NA
CancelAfter	Main	51.286 ns	0.3029 ns	1.00	144 B	1.00
CancelAfter	PR	52.058 ns	1.7330 ns	1.02	144 B	1.00

System.Threading.Tasks.Tests.Perf_AsyncMethods

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EmptyAsyncMethodInvocation	Main	3.731 ns	0.0128 ns	1.00	-	NA
EmptyAsyncMethodInvocation	PR	3.286 ns	0.0038 ns	0.88	-	NA
SingleYieldMethodInvocation	Main	102.221 ns	5.3328 ns	1.00	96 B	1.00
SingleYieldMethodInvocation	PR	100.185 ns	4.8837 ns	0.98	96 B	1.00
Yield	Main	30.483 ns	0.5967 ns	1.00	-	NA
Yield	PR	30.693 ns	1.1908 ns	1.01	-	NA

System.Threading.Tasks.ValueTaskPerfTest

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-UXTJFQ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-WCARJH : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-XVCCJK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HMQJNI : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MaxWarmupIterationCount=10 MinIterationCount=15
MinWarmupIterationCount=2 WarmupCount=-1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Await_FromResult	Main	5.328 ns	0.0110 ns	1.00	-	NA
Await_FromResult	PR	5.446 ns	0.0079 ns	1.02	-	NA
Await_FromCompletedTask	Main	9.748 ns	0.1823 ns	1.00	72 B	1.00
Await_FromCompletedTask	PR	9.318 ns	0.1712 ns	0.96	72 B	1.00
Await_FromCompletedValueTaskSource	Main	15.410 ns	0.2158 ns	1.00	72 B	1.00
Await_FromCompletedValueTaskSource	PR	15.242 ns	0.1697 ns	0.99	72 B	1.00
CreateAndAwait_FromResult	Main	5.281 ns	0.0154 ns	1.00	-	NA
CreateAndAwait_FromResult	PR	5.294 ns	0.0182 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	Main	5.276 ns	0.0160 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	PR	5.312 ns	0.0280 ns	1.01	-	NA
CreateAndAwait_FromCompletedTask	Main	5.774 ns	0.0214 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask	PR	5.914 ns	0.0899 ns	1.02	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	Main	5.817 ns	0.0137 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	PR	6.211 ns	0.0136 ns	1.07	-	NA
CreateAndAwait_FromCompletedValueTaskSource	Main	6.762 ns	0.0108 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource	PR	6.319 ns	0.0094 ns	0.93	-	NA
CreateAndAwait_FromYieldingAsyncMethod	Main	204.260 ns	9.2949 ns	1.00	207 B	1.00
CreateAndAwait_FromYieldingAsyncMethod	PR	212.860 ns	13.1086 ns	1.04	207 B	1.00
CreateAndAwait_FromDelayedTCS	Main	77.672 ns	0.3388 ns	1.00	216 B	1.00
CreateAndAwait_FromDelayedTCS	PR	76.081 ns	0.5506 ns	0.98	216 B	1.00
Copy_PassAsArgumentAndReturn_FromResult	Main	2.842 ns	0.0268 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromResult	PR	2.832 ns	0.0272 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	Main	5.853 ns	0.0244 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	PR	6.085 ns	0.0314 ns	1.04	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	Main	8.025 ns	0.0529 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	PR	7.993 ns	0.0522 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	Main	6.334 ns	0.0582 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	PR	6.310 ns	0.0456 ns	1.00	-	NA

System.Threading.Channels.Tests.UnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	30.37 ns	0.041 ns	1.00	-	NA
TryWriteThenTryRead	PR	30.40 ns	0.034 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	30.35 ns	0.029 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	30.35 ns	0.019 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	49.04 ns	0.016 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	49.30 ns	0.207 ns	1.01	-	NA
PingPong	Main	2,627,902.03 ns	111,019.119 ns	1.00	903 B	1.00
PingPong	PR	2,658,820.31 ns	145,066.288 ns	1.01	901 B	1.00

System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	17.54 ns	0.013 ns	1.00	-	NA
TryWriteThenTryRead	PR	17.54 ns	0.010 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	22.39 ns	0.016 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	22.43 ns	0.025 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	46.94 ns	0.020 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	47.04 ns	0.076 ns	1.00	-	NA
PingPong	Main	2,511,563.26 ns	93,531.184 ns	1.00	901 B	1.00
PingPong	PR	2,627,531.08 ns	129,689.322 ns	1.05	900 B	1.00

System.Threading.Channels.Tests.BoundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	35.91 ns	0.031 ns	1.00	-	NA
TryWriteThenTryRead	PR	35.87 ns	0.019 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	37.57 ns	0.044 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	37.61 ns	0.061 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	47.84 ns	0.043 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	48.03 ns	0.038 ns	1.00	-	NA
PingPong	Main	2,893,666.76 ns	138,789.838 ns	1.00	901 B	1.00
PingPong	PR	2,847,279.72 ns	148,677.365 ns	0.99	901 B	1.00

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/ea54990edbbdbf16145eaa382580240f

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Calling it on every IO completion can become a noticeable CPU cost exactly when the pool is large. Consider enforcing MaxEventPoolCount with a separate Interlocked-updated counter (increment when returning an Event to the pool, decrement when renting) so the hot path avoids Count while still bounding growth.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Checking it on every SocketIOEvent.Execute() adds avoidable overhead on a very hot path and becomes more expensive as the pool grows. Consider tracking an explicit pool size counter (Interlocked) so MaxEventPoolCount can be enforced without calling Count per completion.

 if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[eduardo-vp]

LGTM!

[VSadov]

Thanks!

[VSadov]

To avoid allocating a workitem per every socket/IO event and reduce the number of enqueues to the global queue we use the following pattern:

• Socket/IO engine places the events (a struct) into a concurrent queue, where the storage is naturally reused.
• In order to get the event executed, we post a self-replicating workitem into a global queue and that workitem fetches the events and executes them.
• There is also a heuristic that if the queue runs dry or after some time duration (and in Windows case also in a presence of local workitems) the task stops "pumping" of the events would not starve other workitems.

=== The pattern has some issues that get worse on big core counts:

• The self-replication of the event queue task places copies of itself into the global queue every time a worker starts "pumping" and sees more items in the queue. We must do this for correctness - to make sure that remaining queued events will be eventually picked up even if the current thread blocks.
  This self-requeuing can put a lot of stress on the global queue.
  In a case of assignable queues, the re-queued item ends up in the assignable queue, which are local to a subset of workers, thus may impact p99 latencies.

• When a worker stops dispatching from the event queue (due to time limit, for example) and then picks up an event queue task again, it may be a queue from a different IO engine.
  This randomizes both the assignment of the event queues to workers and the order of event execution.
  It is possible that multiple workers would "pump" events from the same queue, while other queues are neglected (and keep growing if events are arriving).
  A queue that is overshared may cause contentions, spinning/sleeping of workers.

• the event queue is basically a memory cache with no upper bounds. We do not know how big the event queue can get if the enqueuing outruns dequeuing for some nontrivial time.
  We do not report the size of this queue in the ThreadPool Queue Length or any other counter even though these are technically threadpool workitems.

=== What we do instead in this PR:
At the high level instead of relying on a queue to reduce the number of global enqueues (temporal batching), we explicitly combine multiple events into batches of predictable and bounded size and enqueue entire batches to the global queue.

Details:

• IO engine fills actual event workitems (in IThreadPoolWorkItem sense) with data.

• The workitems are reused via a pool that has an upper bound.
  (in an unlikely case that the limit is reached we will allocate/GC the workitems).

• To avoid stressing the global queues, the workitems are packed into balanced binary trees, so that we could submit the entire batch for execution in one enqueue.

• Worker threads, upon executing the parent, place the children into the local queue.
  The current worker is likely still the best worker to execute the children, but if other workers need work they can steal whole subtrees thus divide-and-conquering the remaining work.

• as a general approach if execution of an event results in more than one task, we place the additional tasks into the local queue - to relieve the stress on the global queue, improve the locality of execution and statistically reduce the max workqueue lengths.

• the size of a batch is bounded to make sure that large batches do not impact p99 latency.

=== Perf diffs:

JSON benchmarks

 x64 / HIGH load (56 cores, load 4096 connections, load threads=64)
- base RPS 2,528,080 p50 1.47 ms p99 3.79 ms+ new RPS 2,580,722 p50 1.50 ms p99 3.13 ms
+2.1% +2.0% -17.4%
x64 / LOW load (56 cores, load 512 connections)
- base RPS 2,141,591 p50 0.21 ms p99 0.57 ms+ new RPS 2,177,068 p50 0.21 ms p99 0.59 ms
+1.7% 0.0% +3.5%
arm64 / HIGH load (96 cores, load 4096 connections, load threads=64)
- base RPS 3,715,921 p50 0.57 ms p99 7.30 ms+ new RPS 3,696,351 p50 0.56 ms p99 7.01 ms
-0.5% -1.8% -4.0%
arm64 / LOW load (96 cores, load 256 connections)
- base RPS 2,064,045 p50 0.25 ms p99 0.78 ms+ new RPS 2,149,487 p50 0.25 ms p99 0.44 ms
+4.1% 0.0% -43.6%

The change appears to erase most of the gap with net10 on JSON benchmark in high core configuration, thus:
Fixes: #127484

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR changes how socket / IO completion events are dispatched to the thread pool, replacing the prior “queue + pumping work item” pattern with pooled per-event work items that are submitted in batches via a balanced binary tree to reduce global-queue pressure and bound memory growth.

Changes:

• Remove the Windows-only ThreadPoolTypedWorkItemQueue sub-dispatcher from ThreadPoolWorkQueue.
• Windows IOCP: pool IOCompletionPoller.Event instances and batch-submit completions as a balanced tree, fanning out to local queues as nodes execute.
• Unix sockets: pool SocketIOEvent instances and similarly batch-submit async socket events as a balanced tree; adjust some preferLocal scheduling.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs	Removes the Windows-only typed work item queue implementation previously used for IO sub-dispatch.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs	Introduces pooled Event work items and balanced-tree batching for IOCP completions; changes queueing behavior.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs	Reworks async socket event dispatch to use pooled SocketIOEvent work items and balanced-tree batching.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs	Switches some thread-pool queueing to preferLocal: true for async operation processing/cancellation callbacks.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• Using ConcurrentQueue<T>.Count in the hot path (SocketIOEvent.Execute) can be quite expensive under contention (Count is not O(1) for ConcurrentQueue<T>). Since this runs per completion, it risks regressing throughput and adding cross-thread cache contention. Consider tracking pool size with an explicit int counter (Interlocked increment/decrement on enqueue/dequeue) instead of calling Count here.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• Using ConcurrentQueue<T>.Count in Event.Execute is a potentially expensive operation under contention (Count is not O(1) for ConcurrentQueue<T>). Since this executes per IO completion, it can add avoidable overhead. Consider tracking pool size with an explicit Interlocked counter on borrow/return instead of querying Count here.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it for every completion work item defeats some of the intended perf/throughput wins.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it on every async socket event adds overhead on the hot path.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:102

• The comment above _eventQueue says it’s a queue of events generated by EventLoop, but in this revision _eventQueue is used as a pool of reusable SocketIOEvent instances (see RentEvent and SocketIOEvent.Execute). Updating the comment would prevent future confusion about its semantics and why it’s bounded.

 //
// Queue of events generated by EventLoop() that would be processed by the thread pool
//
private readonly ConcurrentQueue<SocketIOEvent> _eventQueue = new ConcurrentQueue<SocketIOEvent>();

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:512

• Event pooling uses ConcurrentQueue.Count on every completion to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock (see ConcurrentQueue.cs), so calling it in this hot path can add contention/latency and offset the intended allocation savings. Consider using an Interlocked-based approximate pool size counter (increment on Enqueue, decrement on Dequeue) instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:527

• SocketIOEvent pooling uses ConcurrentQueue.Count on every event execution to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock, so this can be a measurable hot-path cost under high IO rates. Consider tracking pool size via an Interlocked counter (increment on Enqueue, decrement on RentEvent dequeue success) instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:509

• Using ConcurrentQueue.Count on every IO completion to enforce the pool bound is potentially expensive. ConcurrentQueue.Count can spin and may take _crossSegmentLock when there are multiple segments (see System.Collections.Concurrent.ConcurrentQueue.Count implementation), which can become a noticeable overhead at high IO rates. Consider tracking pool size with an Interlocked counter (increment on Enqueue, decrement on successful TryDequeue) to keep the bound check O(1) without extra locking.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:533

• SocketIOEvent.Execute() uses ConcurrentQueue.Count to enforce the pool bound. ConcurrentQueue.Count can spin and may take the cross-segment lock when multiple segments exist, so doing this per event can add measurable overhead under heavy IO. Consider maintaining an Interlocked pool-size counter instead of calling Count in the hot path.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue<T>.Count can take _crossSegmentLock (and spin/retry) when the queue has multiple segments, so calling _pool.Count on every completion is a potentially expensive hot-path operation and undermines the goal of reducing overhead. Consider tracking the pool size with an int updated via Interlocked on enqueue/dequeue (best-effort is fine) and use that value for the MaxEventPoolCount check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• _pool.Count is queried for every SocketIOEvent execution. ConcurrentQueue<T>.Count is not a cheap counter; it may spin and can take _crossSegmentLock when multiple segments exist, so this can become a measurable overhead under high event rates. Consider maintaining an int pool size updated via Interlocked on enqueue/dequeue and using that for the MaxEventPoolCount gate instead of Count.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[VSadov]

@MihuBot benchmark System.Threading

[VSadov]

@MihuBot benchmark System.Buffers

[MihuBot]

System.Threading.Tests.Perf_Volatile

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Write_double	Main	0.9338 ns	0.0040 ns	1.00	-	NA
Write_double	PR	0.9317 ns	0.0029 ns	1.00	-	NA
Read_double	Main	0.9485 ns	0.0045 ns	1.00	-	NA
Read_double	PR	0.9459 ns	0.0064 ns	1.00	-	NA

System.Threading.Tests.Perf_Timer

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ShortScheduleAndDispose	Main	74.99 ns	0.395 ns	1.00	120 B	1.00
ShortScheduleAndDispose	PR	75.45 ns	0.697 ns	1.01	120 B	1.00
LongScheduleAndDispose	Main	75.44 ns	0.651 ns	1.00	120 B	1.00
LongScheduleAndDispose	PR	75.34 ns	0.673 ns	1.00	120 B	1.00
ScheduleManyThenDisposeMany	Main	223,379,838.13 ns	1,965,673.532 ns	1.00	144001328 B	1.00
ScheduleManyThenDisposeMany	PR	223,129,600.73 ns	2,591,171.964 ns	1.00	144001328 B	1.00
ShortScheduleAndDisposeWithFiringTimers	Main	80.28 ns	1.599 ns	1.00	144 B	1.00
ShortScheduleAndDisposeWithFiringTimers	PR	80.46 ns	1.515 ns	1.00	144 B	1.00
SynchronousContention	Main	1,420,584,665.07 ns	17,411,095.255 ns	1.00	1152000760 B	1.00
SynchronousContention	PR	1,298,023,677.18 ns	25,870,105.978 ns	0.91	1152000760 B	1.00
AsynchronousContention	Main	1,128,918,393.85 ns	36,890,792.880 ns	1.00	1152002232 B	1.00
AsynchronousContention	PR	1,403,692,668.40 ns	41,823,779.338 ns	1.25	1152002232 B	1.00

System.Threading.Tests.Perf_ThreadStatic

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
GetThreadStatic	Main	1.869 ns	0.0084 ns	1.00	-	NA
GetThreadStatic	PR	1.886 ns	0.0068 ns	1.01	-	NA
SetThreadStatic	Main	3.271 ns	0.0107 ns	1.00	-	NA
SetThreadStatic	PR	3.272 ns	0.0150 ns	1.00	-	NA

System.Threading.Tests.Perf_ThreadPool

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1 Gen0=38000.0000

Method	Toolchain	WorkItemsPerCore	Mean	Error	Ratio	Allocated	Alloc Ratio
QueueUserWorkItem_WaitCallback_Throughput	Main	20000000	1.980 s	0.0144 s	1.00	610.35 MB	1.00
QueueUserWorkItem_WaitCallback_Throughput	PR	20000000	1.965 s	0.0112 s	0.99	610.35 MB	1.00

System.Threading.Tests.Perf_Thread

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
CurrentThread	Main	1.895 ns	0.0140 ns	1.00	-	NA
CurrentThread	PR	1.892 ns	0.0078 ns	1.00	-	NA
GetCurrentProcessorId	Main	2.321 ns	0.0074 ns	1.00	-	NA
GetCurrentProcessorId	PR	2.119 ns	0.0111 ns	0.91	-	NA

System.Threading.Tests.Perf_SpinLock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	10.560 ns	0.0062 ns	1.00	-	NA
EnterExit	PR	10.553 ns	0.0124 ns	1.00	-	NA
TryEnterExit	Main	10.564 ns	0.0055 ns	1.00	-	NA
TryEnterExit	PR	10.546 ns	0.0044 ns	1.00	-	NA
TryEnter_Fail	Main	1.236 ns	0.0054 ns	1.00	-	NA
TryEnter_Fail	PR	1.233 ns	0.0050 ns	1.00	-	NA

System.Threading.Tests.Perf_SemaphoreSlim

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReleaseWait	Main	29.63 ns	0.016 ns	1.00	-	NA
ReleaseWait	PR	29.65 ns	0.014 ns	1.00	-	NA
ReleaseWaitAsync	Main	28.25 ns	0.021 ns	1.00	-	NA
ReleaseWaitAsync	PR	28.26 ns	0.011 ns	1.00	-	NA
ReleaseWaitAsync_WithCancellationToken	Main	317.66 ns	20.687 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithCancellationToken	PR	317.60 ns	22.628 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithTimeout	Main	337.80 ns	17.205 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithTimeout	PR	318.12 ns	7.530 ns	0.94	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	Main	361.32 ns	11.905 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	PR	362.21 ns	17.881 ns	1.00	624 B	1.00

System.Threading.Tests.Perf_Monitor

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	13.55 ns	0.008 ns	1.00	-	NA
EnterExit	PR	13.55 ns	0.006 ns	1.00	-	NA
TryEnterExit	Main	13.55 ns	0.009 ns	1.00	-	NA
TryEnterExit	PR	13.54 ns	0.007 ns	1.00	-	NA

System.Threading.Tests.Perf_Lock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReaderWriterLockSlimPerf	Main	13.55 ns	0.008 ns	1.00	-	NA
ReaderWriterLockSlimPerf	PR	13.55 ns	0.034 ns	1.00	-	NA

System.Threading.Tests.Perf_Interlocked

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Increment_int	Main	4.824 ns	0.0021 ns	1.00	-	NA
Increment_int	PR	4.820 ns	0.0040 ns	1.00	-	NA
Decrement_int	Main	4.829 ns	0.0159 ns	1.00	-	NA
Decrement_int	PR	4.819 ns	0.0018 ns	1.00	-	NA
Increment_long	Main	4.818 ns	0.0025 ns	1.00	-	NA
Increment_long	PR	4.820 ns	0.0016 ns	1.00	-	NA
Decrement_long	Main	4.815 ns	0.0020 ns	1.00	-	NA
Decrement_long	PR	4.820 ns	0.0025 ns	1.00	-	NA
Add_int	Main	4.815 ns	0.0016 ns	1.00	-	NA
Add_int	PR	4.816 ns	0.0022 ns	1.00	-	NA
Add_long	Main	4.817 ns	0.0019 ns	1.00	-	NA
Add_long	PR	4.819 ns	0.0019 ns	1.00	-	NA
Exchange_int	Main	4.819 ns	0.0033 ns	1.00	-	NA
Exchange_int	PR	4.819 ns	0.0048 ns	1.00	-	NA
Exchange_long	Main	4.817 ns	0.0020 ns	1.00	-	NA
Exchange_long	PR	4.820 ns	0.0020 ns	1.00	-	NA
CompareExchange_int	Main	4.829 ns	0.0024 ns	1.00	-	NA
CompareExchange_int	PR	4.830 ns	0.0019 ns	1.00	-	NA
CompareExchange_long	Main	4.832 ns	0.0037 ns	1.00	-	NA
CompareExchange_long	PR	4.831 ns	0.0033 ns	1.00	-	NA
CompareExchange_object_Match	Main	5.509 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_Match	PR	5.508 ns	0.0035 ns	1.00	-	NA
CompareExchange_object_NoMatch	Main	5.510 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_NoMatch	PR	5.508 ns	0.0041 ns	1.00	-	NA

System.Threading.Tests.Perf_EventWaitHandle

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Set_Reset	Main	42.75 ns	0.027 ns	1.00	-	NA
Set_Reset	PR	42.72 ns	0.020 ns	1.00	-	NA

System.Threading.Tests.Perf_CancellationToken

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
RegisterAndUnregister_Serial	Main	18.912 ns	0.0493 ns	1.00	-	NA
RegisterAndUnregister_Serial	PR	18.946 ns	0.1112 ns	1.00	-	NA
Cancel	Main	54.448 ns	0.8583 ns	1.00	192 B	1.00
Cancel	PR	53.189 ns	0.3285 ns	0.98	192 B	1.00
CreateLinkedTokenSource1	Main	21.830 ns	0.3112 ns	1.00	64 B	1.00
CreateLinkedTokenSource1	PR	21.034 ns	0.4128 ns	0.96	64 B	1.00
CreateLinkedTokenSource2	Main	38.236 ns	0.4997 ns	1.00	80 B	1.00
CreateLinkedTokenSource2	PR	37.323 ns	0.1491 ns	0.98	80 B	1.00
CreateLinkedTokenSource3	Main	58.207 ns	0.3793 ns	1.00	128 B	1.00
CreateLinkedTokenSource3	PR	58.819 ns	0.3601 ns	1.01	128 B	1.00
CreateTokenDispose	Main	5.448 ns	0.0367 ns	1.00	48 B	1.00
CreateTokenDispose	PR	5.462 ns	0.0467 ns	1.00	48 B	1.00
CreateRegisterDispose	Main	32.044 ns	0.3211 ns	1.00	192 B	1.00
CreateRegisterDispose	PR	31.946 ns	0.3375 ns	1.00	192 B	1.00
CreateManyRegisterDispose	Main	14.507 ns	0.0215 ns	1.00	-	NA
CreateManyRegisterDispose	PR	14.487 ns	0.0178 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	Main	80.629 ns	0.1873 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	PR	81.699 ns	0.1683 ns	1.01	-	NA
CancelAfter	Main	51.286 ns	0.3029 ns	1.00	144 B	1.00
CancelAfter	PR	52.058 ns	1.7330 ns	1.02	144 B	1.00

System.Threading.Tasks.Tests.Perf_AsyncMethods

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EmptyAsyncMethodInvocation	Main	3.731 ns	0.0128 ns	1.00	-	NA
EmptyAsyncMethodInvocation	PR	3.286 ns	0.0038 ns	0.88	-	NA
SingleYieldMethodInvocation	Main	102.221 ns	5.3328 ns	1.00	96 B	1.00
SingleYieldMethodInvocation	PR	100.185 ns	4.8837 ns	0.98	96 B	1.00
Yield	Main	30.483 ns	0.5967 ns	1.00	-	NA
Yield	PR	30.693 ns	1.1908 ns	1.01	-	NA

System.Threading.Tasks.ValueTaskPerfTest

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-UXTJFQ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-WCARJH : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-XVCCJK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HMQJNI : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MaxWarmupIterationCount=10 MinIterationCount=15
MinWarmupIterationCount=2 WarmupCount=-1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Await_FromResult	Main	5.328 ns	0.0110 ns	1.00	-	NA
Await_FromResult	PR	5.446 ns	0.0079 ns	1.02	-	NA
Await_FromCompletedTask	Main	9.748 ns	0.1823 ns	1.00	72 B	1.00
Await_FromCompletedTask	PR	9.318 ns	0.1712 ns	0.96	72 B	1.00
Await_FromCompletedValueTaskSource	Main	15.410 ns	0.2158 ns	1.00	72 B	1.00
Await_FromCompletedValueTaskSource	PR	15.242 ns	0.1697 ns	0.99	72 B	1.00
CreateAndAwait_FromResult	Main	5.281 ns	0.0154 ns	1.00	-	NA
CreateAndAwait_FromResult	PR	5.294 ns	0.0182 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	Main	5.276 ns	0.0160 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	PR	5.312 ns	0.0280 ns	1.01	-	NA
CreateAndAwait_FromCompletedTask	Main	5.774 ns	0.0214 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask	PR	5.914 ns	0.0899 ns	1.02	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	Main	5.817 ns	0.0137 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	PR	6.211 ns	0.0136 ns	1.07	-	NA
CreateAndAwait_FromCompletedValueTaskSource	Main	6.762 ns	0.0108 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource	PR	6.319 ns	0.0094 ns	0.93	-	NA
CreateAndAwait_FromYieldingAsyncMethod	Main	204.260 ns	9.2949 ns	1.00	207 B	1.00
CreateAndAwait_FromYieldingAsyncMethod	PR	212.860 ns	13.1086 ns	1.04	207 B	1.00
CreateAndAwait_FromDelayedTCS	Main	77.672 ns	0.3388 ns	1.00	216 B	1.00
CreateAndAwait_FromDelayedTCS	PR	76.081 ns	0.5506 ns	0.98	216 B	1.00
Copy_PassAsArgumentAndReturn_FromResult	Main	2.842 ns	0.0268 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromResult	PR	2.832 ns	0.0272 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	Main	5.853 ns	0.0244 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	PR	6.085 ns	0.0314 ns	1.04	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	Main	8.025 ns	0.0529 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	PR	7.993 ns	0.0522 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	Main	6.334 ns	0.0582 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	PR	6.310 ns	0.0456 ns	1.00	-	NA

System.Threading.Channels.Tests.UnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	30.37 ns	0.041 ns	1.00	-	NA
TryWriteThenTryRead	PR	30.40 ns	0.034 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	30.35 ns	0.029 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	30.35 ns	0.019 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	49.04 ns	0.016 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	49.30 ns	0.207 ns	1.01	-	NA
PingPong	Main	2,627,902.03 ns	111,019.119 ns	1.00	903 B	1.00
PingPong	PR	2,658,820.31 ns	145,066.288 ns	1.01	901 B	1.00

System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	17.54 ns	0.013 ns	1.00	-	NA
TryWriteThenTryRead	PR	17.54 ns	0.010 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	22.39 ns	0.016 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	22.43 ns	0.025 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	46.94 ns	0.020 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	47.04 ns	0.076 ns	1.00	-	NA
PingPong	Main	2,511,563.26 ns	93,531.184 ns	1.00	901 B	1.00
PingPong	PR	2,627,531.08 ns	129,689.322 ns	1.05	900 B	1.00

System.Threading.Channels.Tests.BoundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	35.91 ns	0.031 ns	1.00	-	NA
TryWriteThenTryRead	PR	35.87 ns	0.019 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	37.57 ns	0.044 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	37.61 ns	0.061 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	47.84 ns	0.043 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	48.03 ns	0.038 ns	1.00	-	NA
PingPong	Main	2,893,666.76 ns	138,789.838 ns	1.00	901 B	1.00
PingPong	PR	2,847,279.72 ns	148,677.365 ns	0.99	901 B	1.00

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/ea54990edbbdbf16145eaa382580240f

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Calling it on every IO completion can become a noticeable CPU cost exactly when the pool is large. Consider enforcing MaxEventPoolCount with a separate Interlocked-updated counter (increment when returning an Event to the pool, decrement when renting) so the hot path avoids Count while still bounding growth.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Checking it on every SocketIOEvent.Execute() adds avoidable overhead on a very hot path and becomes more expensive as the pool grows. Consider tracking an explicit pool size counter (Interlocked) so MaxEventPoolCount can be enforced without calling Count per completion.

 if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[eduardo-vp]

LGTM!

[VSadov]

Thanks!

[VSadov]

To avoid allocating a workitem per every socket/IO event and reduce the number of enqueues to the global queue we use the following pattern:

• Socket/IO engine places the events (a struct) into a concurrent queue, where the storage is naturally reused.
• In order to get the event executed, we post a self-replicating workitem into a global queue and that workitem fetches the events and executes them.
• There is also a heuristic that if the queue runs dry or after some time duration (and in Windows case also in a presence of local workitems) the task stops "pumping" of the events would not starve other workitems.

=== The pattern has some issues that get worse on big core counts:

• The self-replication of the event queue task places copies of itself into the global queue every time a worker starts "pumping" and sees more items in the queue. We must do this for correctness - to make sure that remaining queued events will be eventually picked up even if the current thread blocks.
  This self-requeuing can put a lot of stress on the global queue.
  In a case of assignable queues, the re-queued item ends up in the assignable queue, which are local to a subset of workers, thus may impact p99 latencies.

• When a worker stops dispatching from the event queue (due to time limit, for example) and then picks up an event queue task again, it may be a queue from a different IO engine.
  This randomizes both the assignment of the event queues to workers and the order of event execution.
  It is possible that multiple workers would "pump" events from the same queue, while other queues are neglected (and keep growing if events are arriving).
  A queue that is overshared may cause contentions, spinning/sleeping of workers.

• the event queue is basically a memory cache with no upper bounds. We do not know how big the event queue can get if the enqueuing outruns dequeuing for some nontrivial time.
  We do not report the size of this queue in the ThreadPool Queue Length or any other counter even though these are technically threadpool workitems.

=== What we do instead in this PR:
At the high level instead of relying on a queue to reduce the number of global enqueues (temporal batching), we explicitly combine multiple events into batches of predictable and bounded size and enqueue entire batches to the global queue.

Details:

• IO engine fills actual event workitems (in IThreadPoolWorkItem sense) with data.

• The workitems are reused via a pool that has an upper bound.
  (in an unlikely case that the limit is reached we will allocate/GC the workitems).

• To avoid stressing the global queues, the workitems are packed into balanced binary trees, so that we could submit the entire batch for execution in one enqueue.

• Worker threads, upon executing the parent, place the children into the local queue.
  The current worker is likely still the best worker to execute the children, but if other workers need work they can steal whole subtrees thus divide-and-conquering the remaining work.

• as a general approach if execution of an event results in more than one task, we place the additional tasks into the local queue - to relieve the stress on the global queue, improve the locality of execution and statistically reduce the max workqueue lengths.

• the size of a batch is bounded to make sure that large batches do not impact p99 latency.

=== Perf diffs:

JSON benchmarks

 x64 / HIGH load (56 cores, load 4096 connections, load threads=64)
- base RPS 2,528,080 p50 1.47 ms p99 3.79 ms+ new RPS 2,580,722 p50 1.50 ms p99 3.13 ms
+2.1% +2.0% -17.4%
x64 / LOW load (56 cores, load 512 connections)
- base RPS 2,141,591 p50 0.21 ms p99 0.57 ms+ new RPS 2,177,068 p50 0.21 ms p99 0.59 ms
+1.7% 0.0% +3.5%
arm64 / HIGH load (96 cores, load 4096 connections, load threads=64)
- base RPS 3,715,921 p50 0.57 ms p99 7.30 ms+ new RPS 3,696,351 p50 0.56 ms p99 7.01 ms
-0.5% -1.8% -4.0%
arm64 / LOW load (96 cores, load 256 connections)
- base RPS 2,064,045 p50 0.25 ms p99 0.78 ms+ new RPS 2,149,487 p50 0.25 ms p99 0.44 ms
+4.1% 0.0% -43.6%

The change appears to erase most of the gap with net10 on JSON benchmark in high core configuration, thus:
Fixes: #127484

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR changes how socket / IO completion events are dispatched to the thread pool, replacing the prior “queue + pumping work item” pattern with pooled per-event work items that are submitted in batches via a balanced binary tree to reduce global-queue pressure and bound memory growth.

Changes:

• Remove the Windows-only ThreadPoolTypedWorkItemQueue sub-dispatcher from ThreadPoolWorkQueue.
• Windows IOCP: pool IOCompletionPoller.Event instances and batch-submit completions as a balanced tree, fanning out to local queues as nodes execute.
• Unix sockets: pool SocketIOEvent instances and similarly batch-submit async socket events as a balanced tree; adjust some preferLocal scheduling.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs	Removes the Windows-only typed work item queue implementation previously used for IO sub-dispatch.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs	Introduces pooled Event work items and balanced-tree batching for IOCP completions; changes queueing behavior.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs	Reworks async socket event dispatch to use pooled SocketIOEvent work items and balanced-tree batching.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs	Switches some thread-pool queueing to preferLocal: true for async operation processing/cancellation callbacks.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• Using ConcurrentQueue<T>.Count in the hot path (SocketIOEvent.Execute) can be quite expensive under contention (Count is not O(1) for ConcurrentQueue<T>). Since this runs per completion, it risks regressing throughput and adding cross-thread cache contention. Consider tracking pool size with an explicit int counter (Interlocked increment/decrement on enqueue/dequeue) instead of calling Count here.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• Using ConcurrentQueue<T>.Count in Event.Execute is a potentially expensive operation under contention (Count is not O(1) for ConcurrentQueue<T>). Since this executes per IO completion, it can add avoidable overhead. Consider tracking pool size with an explicit Interlocked counter on borrow/return instead of querying Count here.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it for every completion work item defeats some of the intended perf/throughput wins.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it on every async socket event adds overhead on the hot path.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:102

• The comment above _eventQueue says it’s a queue of events generated by EventLoop, but in this revision _eventQueue is used as a pool of reusable SocketIOEvent instances (see RentEvent and SocketIOEvent.Execute). Updating the comment would prevent future confusion about its semantics and why it’s bounded.

 //
// Queue of events generated by EventLoop() that would be processed by the thread pool
//
private readonly ConcurrentQueue<SocketIOEvent> _eventQueue = new ConcurrentQueue<SocketIOEvent>();

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:512

• Event pooling uses ConcurrentQueue.Count on every completion to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock (see ConcurrentQueue.cs), so calling it in this hot path can add contention/latency and offset the intended allocation savings. Consider using an Interlocked-based approximate pool size counter (increment on Enqueue, decrement on Dequeue) instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:527

• SocketIOEvent pooling uses ConcurrentQueue.Count on every event execution to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock, so this can be a measurable hot-path cost under high IO rates. Consider tracking pool size via an Interlocked counter (increment on Enqueue, decrement on RentEvent dequeue success) instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:509

• Using ConcurrentQueue.Count on every IO completion to enforce the pool bound is potentially expensive. ConcurrentQueue.Count can spin and may take _crossSegmentLock when there are multiple segments (see System.Collections.Concurrent.ConcurrentQueue.Count implementation), which can become a noticeable overhead at high IO rates. Consider tracking pool size with an Interlocked counter (increment on Enqueue, decrement on successful TryDequeue) to keep the bound check O(1) without extra locking.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:533

• SocketIOEvent.Execute() uses ConcurrentQueue.Count to enforce the pool bound. ConcurrentQueue.Count can spin and may take the cross-segment lock when multiple segments exist, so doing this per event can add measurable overhead under heavy IO. Consider maintaining an Interlocked pool-size counter instead of calling Count in the hot path.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue<T>.Count can take _crossSegmentLock (and spin/retry) when the queue has multiple segments, so calling _pool.Count on every completion is a potentially expensive hot-path operation and undermines the goal of reducing overhead. Consider tracking the pool size with an int updated via Interlocked on enqueue/dequeue (best-effort is fine) and use that value for the MaxEventPoolCount check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• _pool.Count is queried for every SocketIOEvent execution. ConcurrentQueue<T>.Count is not a cheap counter; it may spin and can take _crossSegmentLock when multiple segments exist, so this can become a measurable overhead under high event rates. Consider maintaining an int pool size updated via Interlocked on enqueue/dequeue and using that for the MaxEventPoolCount gate instead of Count.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[VSadov]

@MihuBot benchmark System.Threading

[VSadov]

@MihuBot benchmark System.Buffers

[MihuBot]

System.Threading.Tests.Perf_Volatile

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Write_double	Main	0.9338 ns	0.0040 ns	1.00	-	NA
Write_double	PR	0.9317 ns	0.0029 ns	1.00	-	NA
Read_double	Main	0.9485 ns	0.0045 ns	1.00	-	NA
Read_double	PR	0.9459 ns	0.0064 ns	1.00	-	NA

System.Threading.Tests.Perf_Timer

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ShortScheduleAndDispose	Main	74.99 ns	0.395 ns	1.00	120 B	1.00
ShortScheduleAndDispose	PR	75.45 ns	0.697 ns	1.01	120 B	1.00
LongScheduleAndDispose	Main	75.44 ns	0.651 ns	1.00	120 B	1.00
LongScheduleAndDispose	PR	75.34 ns	0.673 ns	1.00	120 B	1.00
ScheduleManyThenDisposeMany	Main	223,379,838.13 ns	1,965,673.532 ns	1.00	144001328 B	1.00
ScheduleManyThenDisposeMany	PR	223,129,600.73 ns	2,591,171.964 ns	1.00	144001328 B	1.00
ShortScheduleAndDisposeWithFiringTimers	Main	80.28 ns	1.599 ns	1.00	144 B	1.00
ShortScheduleAndDisposeWithFiringTimers	PR	80.46 ns	1.515 ns	1.00	144 B	1.00
SynchronousContention	Main	1,420,584,665.07 ns	17,411,095.255 ns	1.00	1152000760 B	1.00
SynchronousContention	PR	1,298,023,677.18 ns	25,870,105.978 ns	0.91	1152000760 B	1.00
AsynchronousContention	Main	1,128,918,393.85 ns	36,890,792.880 ns	1.00	1152002232 B	1.00
AsynchronousContention	PR	1,403,692,668.40 ns	41,823,779.338 ns	1.25	1152002232 B	1.00

System.Threading.Tests.Perf_ThreadStatic

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
GetThreadStatic	Main	1.869 ns	0.0084 ns	1.00	-	NA
GetThreadStatic	PR	1.886 ns	0.0068 ns	1.01	-	NA
SetThreadStatic	Main	3.271 ns	0.0107 ns	1.00	-	NA
SetThreadStatic	PR	3.272 ns	0.0150 ns	1.00	-	NA

System.Threading.Tests.Perf_ThreadPool

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1 Gen0=38000.0000

Method	Toolchain	WorkItemsPerCore	Mean	Error	Ratio	Allocated	Alloc Ratio
QueueUserWorkItem_WaitCallback_Throughput	Main	20000000	1.980 s	0.0144 s	1.00	610.35 MB	1.00
QueueUserWorkItem_WaitCallback_Throughput	PR	20000000	1.965 s	0.0112 s	0.99	610.35 MB	1.00

System.Threading.Tests.Perf_Thread

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
CurrentThread	Main	1.895 ns	0.0140 ns	1.00	-	NA
CurrentThread	PR	1.892 ns	0.0078 ns	1.00	-	NA
GetCurrentProcessorId	Main	2.321 ns	0.0074 ns	1.00	-	NA
GetCurrentProcessorId	PR	2.119 ns	0.0111 ns	0.91	-	NA

System.Threading.Tests.Perf_SpinLock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	10.560 ns	0.0062 ns	1.00	-	NA
EnterExit	PR	10.553 ns	0.0124 ns	1.00	-	NA
TryEnterExit	Main	10.564 ns	0.0055 ns	1.00	-	NA
TryEnterExit	PR	10.546 ns	0.0044 ns	1.00	-	NA
TryEnter_Fail	Main	1.236 ns	0.0054 ns	1.00	-	NA
TryEnter_Fail	PR	1.233 ns	0.0050 ns	1.00	-	NA

System.Threading.Tests.Perf_SemaphoreSlim

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReleaseWait	Main	29.63 ns	0.016 ns	1.00	-	NA
ReleaseWait	PR	29.65 ns	0.014 ns	1.00	-	NA
ReleaseWaitAsync	Main	28.25 ns	0.021 ns	1.00	-	NA
ReleaseWaitAsync	PR	28.26 ns	0.011 ns	1.00	-	NA
ReleaseWaitAsync_WithCancellationToken	Main	317.66 ns	20.687 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithCancellationToken	PR	317.60 ns	22.628 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithTimeout	Main	337.80 ns	17.205 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithTimeout	PR	318.12 ns	7.530 ns	0.94	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	Main	361.32 ns	11.905 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	PR	362.21 ns	17.881 ns	1.00	624 B	1.00

System.Threading.Tests.Perf_Monitor

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	13.55 ns	0.008 ns	1.00	-	NA
EnterExit	PR	13.55 ns	0.006 ns	1.00	-	NA
TryEnterExit	Main	13.55 ns	0.009 ns	1.00	-	NA
TryEnterExit	PR	13.54 ns	0.007 ns	1.00	-	NA

System.Threading.Tests.Perf_Lock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReaderWriterLockSlimPerf	Main	13.55 ns	0.008 ns	1.00	-	NA
ReaderWriterLockSlimPerf	PR	13.55 ns	0.034 ns	1.00	-	NA

System.Threading.Tests.Perf_Interlocked

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Increment_int	Main	4.824 ns	0.0021 ns	1.00	-	NA
Increment_int	PR	4.820 ns	0.0040 ns	1.00	-	NA
Decrement_int	Main	4.829 ns	0.0159 ns	1.00	-	NA
Decrement_int	PR	4.819 ns	0.0018 ns	1.00	-	NA
Increment_long	Main	4.818 ns	0.0025 ns	1.00	-	NA
Increment_long	PR	4.820 ns	0.0016 ns	1.00	-	NA
Decrement_long	Main	4.815 ns	0.0020 ns	1.00	-	NA
Decrement_long	PR	4.820 ns	0.0025 ns	1.00	-	NA
Add_int	Main	4.815 ns	0.0016 ns	1.00	-	NA
Add_int	PR	4.816 ns	0.0022 ns	1.00	-	NA
Add_long	Main	4.817 ns	0.0019 ns	1.00	-	NA
Add_long	PR	4.819 ns	0.0019 ns	1.00	-	NA
Exchange_int	Main	4.819 ns	0.0033 ns	1.00	-	NA
Exchange_int	PR	4.819 ns	0.0048 ns	1.00	-	NA
Exchange_long	Main	4.817 ns	0.0020 ns	1.00	-	NA
Exchange_long	PR	4.820 ns	0.0020 ns	1.00	-	NA
CompareExchange_int	Main	4.829 ns	0.0024 ns	1.00	-	NA
CompareExchange_int	PR	4.830 ns	0.0019 ns	1.00	-	NA
CompareExchange_long	Main	4.832 ns	0.0037 ns	1.00	-	NA
CompareExchange_long	PR	4.831 ns	0.0033 ns	1.00	-	NA
CompareExchange_object_Match	Main	5.509 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_Match	PR	5.508 ns	0.0035 ns	1.00	-	NA
CompareExchange_object_NoMatch	Main	5.510 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_NoMatch	PR	5.508 ns	0.0041 ns	1.00	-	NA

System.Threading.Tests.Perf_EventWaitHandle

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Set_Reset	Main	42.75 ns	0.027 ns	1.00	-	NA
Set_Reset	PR	42.72 ns	0.020 ns	1.00	-	NA

System.Threading.Tests.Perf_CancellationToken

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
RegisterAndUnregister_Serial	Main	18.912 ns	0.0493 ns	1.00	-	NA
RegisterAndUnregister_Serial	PR	18.946 ns	0.1112 ns	1.00	-	NA
Cancel	Main	54.448 ns	0.8583 ns	1.00	192 B	1.00
Cancel	PR	53.189 ns	0.3285 ns	0.98	192 B	1.00
CreateLinkedTokenSource1	Main	21.830 ns	0.3112 ns	1.00	64 B	1.00
CreateLinkedTokenSource1	PR	21.034 ns	0.4128 ns	0.96	64 B	1.00
CreateLinkedTokenSource2	Main	38.236 ns	0.4997 ns	1.00	80 B	1.00
CreateLinkedTokenSource2	PR	37.323 ns	0.1491 ns	0.98	80 B	1.00
CreateLinkedTokenSource3	Main	58.207 ns	0.3793 ns	1.00	128 B	1.00
CreateLinkedTokenSource3	PR	58.819 ns	0.3601 ns	1.01	128 B	1.00
CreateTokenDispose	Main	5.448 ns	0.0367 ns	1.00	48 B	1.00
CreateTokenDispose	PR	5.462 ns	0.0467 ns	1.00	48 B	1.00
CreateRegisterDispose	Main	32.044 ns	0.3211 ns	1.00	192 B	1.00
CreateRegisterDispose	PR	31.946 ns	0.3375 ns	1.00	192 B	1.00
CreateManyRegisterDispose	Main	14.507 ns	0.0215 ns	1.00	-	NA
CreateManyRegisterDispose	PR	14.487 ns	0.0178 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	Main	80.629 ns	0.1873 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	PR	81.699 ns	0.1683 ns	1.01	-	NA
CancelAfter	Main	51.286 ns	0.3029 ns	1.00	144 B	1.00
CancelAfter	PR	52.058 ns	1.7330 ns	1.02	144 B	1.00

System.Threading.Tasks.Tests.Perf_AsyncMethods

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EmptyAsyncMethodInvocation	Main	3.731 ns	0.0128 ns	1.00	-	NA
EmptyAsyncMethodInvocation	PR	3.286 ns	0.0038 ns	0.88	-	NA
SingleYieldMethodInvocation	Main	102.221 ns	5.3328 ns	1.00	96 B	1.00
SingleYieldMethodInvocation	PR	100.185 ns	4.8837 ns	0.98	96 B	1.00
Yield	Main	30.483 ns	0.5967 ns	1.00	-	NA
Yield	PR	30.693 ns	1.1908 ns	1.01	-	NA

System.Threading.Tasks.ValueTaskPerfTest

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-UXTJFQ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-WCARJH : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-XVCCJK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HMQJNI : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MaxWarmupIterationCount=10 MinIterationCount=15
MinWarmupIterationCount=2 WarmupCount=-1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Await_FromResult	Main	5.328 ns	0.0110 ns	1.00	-	NA
Await_FromResult	PR	5.446 ns	0.0079 ns	1.02	-	NA
Await_FromCompletedTask	Main	9.748 ns	0.1823 ns	1.00	72 B	1.00
Await_FromCompletedTask	PR	9.318 ns	0.1712 ns	0.96	72 B	1.00
Await_FromCompletedValueTaskSource	Main	15.410 ns	0.2158 ns	1.00	72 B	1.00
Await_FromCompletedValueTaskSource	PR	15.242 ns	0.1697 ns	0.99	72 B	1.00
CreateAndAwait_FromResult	Main	5.281 ns	0.0154 ns	1.00	-	NA
CreateAndAwait_FromResult	PR	5.294 ns	0.0182 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	Main	5.276 ns	0.0160 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	PR	5.312 ns	0.0280 ns	1.01	-	NA
CreateAndAwait_FromCompletedTask	Main	5.774 ns	0.0214 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask	PR	5.914 ns	0.0899 ns	1.02	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	Main	5.817 ns	0.0137 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	PR	6.211 ns	0.0136 ns	1.07	-	NA
CreateAndAwait_FromCompletedValueTaskSource	Main	6.762 ns	0.0108 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource	PR	6.319 ns	0.0094 ns	0.93	-	NA
CreateAndAwait_FromYieldingAsyncMethod	Main	204.260 ns	9.2949 ns	1.00	207 B	1.00
CreateAndAwait_FromYieldingAsyncMethod	PR	212.860 ns	13.1086 ns	1.04	207 B	1.00
CreateAndAwait_FromDelayedTCS	Main	77.672 ns	0.3388 ns	1.00	216 B	1.00
CreateAndAwait_FromDelayedTCS	PR	76.081 ns	0.5506 ns	0.98	216 B	1.00
Copy_PassAsArgumentAndReturn_FromResult	Main	2.842 ns	0.0268 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromResult	PR	2.832 ns	0.0272 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	Main	5.853 ns	0.0244 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	PR	6.085 ns	0.0314 ns	1.04	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	Main	8.025 ns	0.0529 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	PR	7.993 ns	0.0522 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	Main	6.334 ns	0.0582 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	PR	6.310 ns	0.0456 ns	1.00	-	NA

System.Threading.Channels.Tests.UnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	30.37 ns	0.041 ns	1.00	-	NA
TryWriteThenTryRead	PR	30.40 ns	0.034 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	30.35 ns	0.029 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	30.35 ns	0.019 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	49.04 ns	0.016 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	49.30 ns	0.207 ns	1.01	-	NA
PingPong	Main	2,627,902.03 ns	111,019.119 ns	1.00	903 B	1.00
PingPong	PR	2,658,820.31 ns	145,066.288 ns	1.01	901 B	1.00

System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	17.54 ns	0.013 ns	1.00	-	NA
TryWriteThenTryRead	PR	17.54 ns	0.010 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	22.39 ns	0.016 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	22.43 ns	0.025 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	46.94 ns	0.020 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	47.04 ns	0.076 ns	1.00	-	NA
PingPong	Main	2,511,563.26 ns	93,531.184 ns	1.00	901 B	1.00
PingPong	PR	2,627,531.08 ns	129,689.322 ns	1.05	900 B	1.00

System.Threading.Channels.Tests.BoundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	35.91 ns	0.031 ns	1.00	-	NA
TryWriteThenTryRead	PR	35.87 ns	0.019 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	37.57 ns	0.044 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	37.61 ns	0.061 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	47.84 ns	0.043 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	48.03 ns	0.038 ns	1.00	-	NA
PingPong	Main	2,893,666.76 ns	138,789.838 ns	1.00	901 B	1.00
PingPong	PR	2,847,279.72 ns	148,677.365 ns	0.99	901 B	1.00

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/ea54990edbbdbf16145eaa382580240f

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Calling it on every IO completion can become a noticeable CPU cost exactly when the pool is large. Consider enforcing MaxEventPoolCount with a separate Interlocked-updated counter (increment when returning an Event to the pool, decrement when renting) so the hot path avoids Count while still bounding growth.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Checking it on every SocketIOEvent.Execute() adds avoidable overhead on a very hot path and becomes more expensive as the pool grows. Consider tracking an explicit pool size counter (Interlocked) so MaxEventPoolCount can be enforced without calling Count per completion.

 if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[eduardo-vp]

LGTM!

[VSadov]

Thanks!

[VSadov]

To avoid allocating a workitem per every socket/IO event and reduce the number of enqueues to the global queue we use the following pattern:

• Socket/IO engine places the events (a struct) into a concurrent queue, where the storage is naturally reused.
• In order to get the event executed, we post a self-replicating workitem into a global queue and that workitem fetches the events and executes them.
• There is also a heuristic that if the queue runs dry or after some time duration (and in Windows case also in a presence of local workitems) the task stops "pumping" of the events would not starve other workitems.

=== The pattern has some issues that get worse on big core counts:

• The self-replication of the event queue task places copies of itself into the global queue every time a worker starts "pumping" and sees more items in the queue. We must do this for correctness - to make sure that remaining queued events will be eventually picked up even if the current thread blocks.
  This self-requeuing can put a lot of stress on the global queue.
  In a case of assignable queues, the re-queued item ends up in the assignable queue, which are local to a subset of workers, thus may impact p99 latencies.

• When a worker stops dispatching from the event queue (due to time limit, for example) and then picks up an event queue task again, it may be a queue from a different IO engine.
  This randomizes both the assignment of the event queues to workers and the order of event execution.
  It is possible that multiple workers would "pump" events from the same queue, while other queues are neglected (and keep growing if events are arriving).
  A queue that is overshared may cause contentions, spinning/sleeping of workers.

• the event queue is basically a memory cache with no upper bounds. We do not know how big the event queue can get if the enqueuing outruns dequeuing for some nontrivial time.
  We do not report the size of this queue in the ThreadPool Queue Length or any other counter even though these are technically threadpool workitems.

=== What we do instead in this PR:
At the high level instead of relying on a queue to reduce the number of global enqueues (temporal batching), we explicitly combine multiple events into batches of predictable and bounded size and enqueue entire batches to the global queue.

Details:

• IO engine fills actual event workitems (in IThreadPoolWorkItem sense) with data.

• The workitems are reused via a pool that has an upper bound.
  (in an unlikely case that the limit is reached we will allocate/GC the workitems).

• To avoid stressing the global queues, the workitems are packed into balanced binary trees, so that we could submit the entire batch for execution in one enqueue.

• Worker threads, upon executing the parent, place the children into the local queue.
  The current worker is likely still the best worker to execute the children, but if other workers need work they can steal whole subtrees thus divide-and-conquering the remaining work.

• as a general approach if execution of an event results in more than one task, we place the additional tasks into the local queue - to relieve the stress on the global queue, improve the locality of execution and statistically reduce the max workqueue lengths.

• the size of a batch is bounded to make sure that large batches do not impact p99 latency.

=== Perf diffs:

JSON benchmarks

 x64 / HIGH load (56 cores, load 4096 connections, load threads=64)
- base RPS 2,528,080 p50 1.47 ms p99 3.79 ms+ new RPS 2,580,722 p50 1.50 ms p99 3.13 ms
+2.1% +2.0% -17.4%
x64 / LOW load (56 cores, load 512 connections)
- base RPS 2,141,591 p50 0.21 ms p99 0.57 ms+ new RPS 2,177,068 p50 0.21 ms p99 0.59 ms
+1.7% 0.0% +3.5%
arm64 / HIGH load (96 cores, load 4096 connections, load threads=64)
- base RPS 3,715,921 p50 0.57 ms p99 7.30 ms+ new RPS 3,696,351 p50 0.56 ms p99 7.01 ms
-0.5% -1.8% -4.0%
arm64 / LOW load (96 cores, load 256 connections)
- base RPS 2,064,045 p50 0.25 ms p99 0.78 ms+ new RPS 2,149,487 p50 0.25 ms p99 0.44 ms
+4.1% 0.0% -43.6%

The change appears to erase most of the gap with net10 on JSON benchmark in high core configuration, thus:
Fixes: #127484

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR changes how socket / IO completion events are dispatched to the thread pool, replacing the prior “queue + pumping work item” pattern with pooled per-event work items that are submitted in batches via a balanced binary tree to reduce global-queue pressure and bound memory growth.

Changes:

• Remove the Windows-only ThreadPoolTypedWorkItemQueue sub-dispatcher from ThreadPoolWorkQueue.
• Windows IOCP: pool IOCompletionPoller.Event instances and batch-submit completions as a balanced tree, fanning out to local queues as nodes execute.
• Unix sockets: pool SocketIOEvent instances and similarly batch-submit async socket events as a balanced tree; adjust some preferLocal scheduling.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs	Removes the Windows-only typed work item queue implementation previously used for IO sub-dispatch.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs	Introduces pooled Event work items and balanced-tree batching for IOCP completions; changes queueing behavior.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs	Reworks async socket event dispatch to use pooled SocketIOEvent work items and balanced-tree batching.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs	Switches some thread-pool queueing to preferLocal: true for async operation processing/cancellation callbacks.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• Using ConcurrentQueue<T>.Count in the hot path (SocketIOEvent.Execute) can be quite expensive under contention (Count is not O(1) for ConcurrentQueue<T>). Since this runs per completion, it risks regressing throughput and adding cross-thread cache contention. Consider tracking pool size with an explicit int counter (Interlocked increment/decrement on enqueue/dequeue) instead of calling Count here.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• Using ConcurrentQueue<T>.Count in Event.Execute is a potentially expensive operation under contention (Count is not O(1) for ConcurrentQueue<T>). Since this executes per IO completion, it can add avoidable overhead. Consider tracking pool size with an explicit Interlocked counter on borrow/return instead of querying Count here.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it for every completion work item defeats some of the intended perf/throughput wins.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it on every async socket event adds overhead on the hot path.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:102

• The comment above _eventQueue says it’s a queue of events generated by EventLoop, but in this revision _eventQueue is used as a pool of reusable SocketIOEvent instances (see RentEvent and SocketIOEvent.Execute). Updating the comment would prevent future confusion about its semantics and why it’s bounded.

 //
// Queue of events generated by EventLoop() that would be processed by the thread pool
//
private readonly ConcurrentQueue<SocketIOEvent> _eventQueue = new ConcurrentQueue<SocketIOEvent>();

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:512

• Event pooling uses ConcurrentQueue.Count on every completion to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock (see ConcurrentQueue.cs), so calling it in this hot path can add contention/latency and offset the intended allocation savings. Consider using an Interlocked-based approximate pool size counter (increment on Enqueue, decrement on Dequeue) instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:527

• SocketIOEvent pooling uses ConcurrentQueue.Count on every event execution to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock, so this can be a measurable hot-path cost under high IO rates. Consider tracking pool size via an Interlocked counter (increment on Enqueue, decrement on RentEvent dequeue success) instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:509

• Using ConcurrentQueue.Count on every IO completion to enforce the pool bound is potentially expensive. ConcurrentQueue.Count can spin and may take _crossSegmentLock when there are multiple segments (see System.Collections.Concurrent.ConcurrentQueue.Count implementation), which can become a noticeable overhead at high IO rates. Consider tracking pool size with an Interlocked counter (increment on Enqueue, decrement on successful TryDequeue) to keep the bound check O(1) without extra locking.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:533

• SocketIOEvent.Execute() uses ConcurrentQueue.Count to enforce the pool bound. ConcurrentQueue.Count can spin and may take the cross-segment lock when multiple segments exist, so doing this per event can add measurable overhead under heavy IO. Consider maintaining an Interlocked pool-size counter instead of calling Count in the hot path.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue<T>.Count can take _crossSegmentLock (and spin/retry) when the queue has multiple segments, so calling _pool.Count on every completion is a potentially expensive hot-path operation and undermines the goal of reducing overhead. Consider tracking the pool size with an int updated via Interlocked on enqueue/dequeue (best-effort is fine) and use that value for the MaxEventPoolCount check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• _pool.Count is queried for every SocketIOEvent execution. ConcurrentQueue<T>.Count is not a cheap counter; it may spin and can take _crossSegmentLock when multiple segments exist, so this can become a measurable overhead under high event rates. Consider maintaining an int pool size updated via Interlocked on enqueue/dequeue and using that for the MaxEventPoolCount gate instead of Count.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[VSadov]

@MihuBot benchmark System.Threading

[VSadov]

@MihuBot benchmark System.Buffers

[MihuBot]

System.Threading.Tests.Perf_Volatile

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Write_double	Main	0.9338 ns	0.0040 ns	1.00	-	NA
Write_double	PR	0.9317 ns	0.0029 ns	1.00	-	NA
Read_double	Main	0.9485 ns	0.0045 ns	1.00	-	NA
Read_double	PR	0.9459 ns	0.0064 ns	1.00	-	NA

System.Threading.Tests.Perf_Timer

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ShortScheduleAndDispose	Main	74.99 ns	0.395 ns	1.00	120 B	1.00
ShortScheduleAndDispose	PR	75.45 ns	0.697 ns	1.01	120 B	1.00
LongScheduleAndDispose	Main	75.44 ns	0.651 ns	1.00	120 B	1.00
LongScheduleAndDispose	PR	75.34 ns	0.673 ns	1.00	120 B	1.00
ScheduleManyThenDisposeMany	Main	223,379,838.13 ns	1,965,673.532 ns	1.00	144001328 B	1.00
ScheduleManyThenDisposeMany	PR	223,129,600.73 ns	2,591,171.964 ns	1.00	144001328 B	1.00
ShortScheduleAndDisposeWithFiringTimers	Main	80.28 ns	1.599 ns	1.00	144 B	1.00
ShortScheduleAndDisposeWithFiringTimers	PR	80.46 ns	1.515 ns	1.00	144 B	1.00
SynchronousContention	Main	1,420,584,665.07 ns	17,411,095.255 ns	1.00	1152000760 B	1.00
SynchronousContention	PR	1,298,023,677.18 ns	25,870,105.978 ns	0.91	1152000760 B	1.00
AsynchronousContention	Main	1,128,918,393.85 ns	36,890,792.880 ns	1.00	1152002232 B	1.00
AsynchronousContention	PR	1,403,692,668.40 ns	41,823,779.338 ns	1.25	1152002232 B	1.00

System.Threading.Tests.Perf_ThreadStatic

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
GetThreadStatic	Main	1.869 ns	0.0084 ns	1.00	-	NA
GetThreadStatic	PR	1.886 ns	0.0068 ns	1.01	-	NA
SetThreadStatic	Main	3.271 ns	0.0107 ns	1.00	-	NA
SetThreadStatic	PR	3.272 ns	0.0150 ns	1.00	-	NA

System.Threading.Tests.Perf_ThreadPool

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1 Gen0=38000.0000

Method	Toolchain	WorkItemsPerCore	Mean	Error	Ratio	Allocated	Alloc Ratio
QueueUserWorkItem_WaitCallback_Throughput	Main	20000000	1.980 s	0.0144 s	1.00	610.35 MB	1.00
QueueUserWorkItem_WaitCallback_Throughput	PR	20000000	1.965 s	0.0112 s	0.99	610.35 MB	1.00

System.Threading.Tests.Perf_Thread

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
CurrentThread	Main	1.895 ns	0.0140 ns	1.00	-	NA
CurrentThread	PR	1.892 ns	0.0078 ns	1.00	-	NA
GetCurrentProcessorId	Main	2.321 ns	0.0074 ns	1.00	-	NA
GetCurrentProcessorId	PR	2.119 ns	0.0111 ns	0.91	-	NA

System.Threading.Tests.Perf_SpinLock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	10.560 ns	0.0062 ns	1.00	-	NA
EnterExit	PR	10.553 ns	0.0124 ns	1.00	-	NA
TryEnterExit	Main	10.564 ns	0.0055 ns	1.00	-	NA
TryEnterExit	PR	10.546 ns	0.0044 ns	1.00	-	NA
TryEnter_Fail	Main	1.236 ns	0.0054 ns	1.00	-	NA
TryEnter_Fail	PR	1.233 ns	0.0050 ns	1.00	-	NA

System.Threading.Tests.Perf_SemaphoreSlim

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReleaseWait	Main	29.63 ns	0.016 ns	1.00	-	NA
ReleaseWait	PR	29.65 ns	0.014 ns	1.00	-	NA
ReleaseWaitAsync	Main	28.25 ns	0.021 ns	1.00	-	NA
ReleaseWaitAsync	PR	28.26 ns	0.011 ns	1.00	-	NA
ReleaseWaitAsync_WithCancellationToken	Main	317.66 ns	20.687 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithCancellationToken	PR	317.60 ns	22.628 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithTimeout	Main	337.80 ns	17.205 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithTimeout	PR	318.12 ns	7.530 ns	0.94	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	Main	361.32 ns	11.905 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	PR	362.21 ns	17.881 ns	1.00	624 B	1.00

System.Threading.Tests.Perf_Monitor

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	13.55 ns	0.008 ns	1.00	-	NA
EnterExit	PR	13.55 ns	0.006 ns	1.00	-	NA
TryEnterExit	Main	13.55 ns	0.009 ns	1.00	-	NA
TryEnterExit	PR	13.54 ns	0.007 ns	1.00	-	NA

System.Threading.Tests.Perf_Lock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReaderWriterLockSlimPerf	Main	13.55 ns	0.008 ns	1.00	-	NA
ReaderWriterLockSlimPerf	PR	13.55 ns	0.034 ns	1.00	-	NA

System.Threading.Tests.Perf_Interlocked

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Increment_int	Main	4.824 ns	0.0021 ns	1.00	-	NA
Increment_int	PR	4.820 ns	0.0040 ns	1.00	-	NA
Decrement_int	Main	4.829 ns	0.0159 ns	1.00	-	NA
Decrement_int	PR	4.819 ns	0.0018 ns	1.00	-	NA
Increment_long	Main	4.818 ns	0.0025 ns	1.00	-	NA
Increment_long	PR	4.820 ns	0.0016 ns	1.00	-	NA
Decrement_long	Main	4.815 ns	0.0020 ns	1.00	-	NA
Decrement_long	PR	4.820 ns	0.0025 ns	1.00	-	NA
Add_int	Main	4.815 ns	0.0016 ns	1.00	-	NA
Add_int	PR	4.816 ns	0.0022 ns	1.00	-	NA
Add_long	Main	4.817 ns	0.0019 ns	1.00	-	NA
Add_long	PR	4.819 ns	0.0019 ns	1.00	-	NA
Exchange_int	Main	4.819 ns	0.0033 ns	1.00	-	NA
Exchange_int	PR	4.819 ns	0.0048 ns	1.00	-	NA
Exchange_long	Main	4.817 ns	0.0020 ns	1.00	-	NA
Exchange_long	PR	4.820 ns	0.0020 ns	1.00	-	NA
CompareExchange_int	Main	4.829 ns	0.0024 ns	1.00	-	NA
CompareExchange_int	PR	4.830 ns	0.0019 ns	1.00	-	NA
CompareExchange_long	Main	4.832 ns	0.0037 ns	1.00	-	NA
CompareExchange_long	PR	4.831 ns	0.0033 ns	1.00	-	NA
CompareExchange_object_Match	Main	5.509 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_Match	PR	5.508 ns	0.0035 ns	1.00	-	NA
CompareExchange_object_NoMatch	Main	5.510 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_NoMatch	PR	5.508 ns	0.0041 ns	1.00	-	NA

System.Threading.Tests.Perf_EventWaitHandle

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Set_Reset	Main	42.75 ns	0.027 ns	1.00	-	NA
Set_Reset	PR	42.72 ns	0.020 ns	1.00	-	NA

System.Threading.Tests.Perf_CancellationToken

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
RegisterAndUnregister_Serial	Main	18.912 ns	0.0493 ns	1.00	-	NA
RegisterAndUnregister_Serial	PR	18.946 ns	0.1112 ns	1.00	-	NA
Cancel	Main	54.448 ns	0.8583 ns	1.00	192 B	1.00
Cancel	PR	53.189 ns	0.3285 ns	0.98	192 B	1.00
CreateLinkedTokenSource1	Main	21.830 ns	0.3112 ns	1.00	64 B	1.00
CreateLinkedTokenSource1	PR	21.034 ns	0.4128 ns	0.96	64 B	1.00
CreateLinkedTokenSource2	Main	38.236 ns	0.4997 ns	1.00	80 B	1.00
CreateLinkedTokenSource2	PR	37.323 ns	0.1491 ns	0.98	80 B	1.00
CreateLinkedTokenSource3	Main	58.207 ns	0.3793 ns	1.00	128 B	1.00
CreateLinkedTokenSource3	PR	58.819 ns	0.3601 ns	1.01	128 B	1.00
CreateTokenDispose	Main	5.448 ns	0.0367 ns	1.00	48 B	1.00
CreateTokenDispose	PR	5.462 ns	0.0467 ns	1.00	48 B	1.00
CreateRegisterDispose	Main	32.044 ns	0.3211 ns	1.00	192 B	1.00
CreateRegisterDispose	PR	31.946 ns	0.3375 ns	1.00	192 B	1.00
CreateManyRegisterDispose	Main	14.507 ns	0.0215 ns	1.00	-	NA
CreateManyRegisterDispose	PR	14.487 ns	0.0178 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	Main	80.629 ns	0.1873 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	PR	81.699 ns	0.1683 ns	1.01	-	NA
CancelAfter	Main	51.286 ns	0.3029 ns	1.00	144 B	1.00
CancelAfter	PR	52.058 ns	1.7330 ns	1.02	144 B	1.00

System.Threading.Tasks.Tests.Perf_AsyncMethods

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EmptyAsyncMethodInvocation	Main	3.731 ns	0.0128 ns	1.00	-	NA
EmptyAsyncMethodInvocation	PR	3.286 ns	0.0038 ns	0.88	-	NA
SingleYieldMethodInvocation	Main	102.221 ns	5.3328 ns	1.00	96 B	1.00
SingleYieldMethodInvocation	PR	100.185 ns	4.8837 ns	0.98	96 B	1.00
Yield	Main	30.483 ns	0.5967 ns	1.00	-	NA
Yield	PR	30.693 ns	1.1908 ns	1.01	-	NA

System.Threading.Tasks.ValueTaskPerfTest

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-UXTJFQ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-WCARJH : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-XVCCJK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HMQJNI : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MaxWarmupIterationCount=10 MinIterationCount=15
MinWarmupIterationCount=2 WarmupCount=-1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Await_FromResult	Main	5.328 ns	0.0110 ns	1.00	-	NA
Await_FromResult	PR	5.446 ns	0.0079 ns	1.02	-	NA
Await_FromCompletedTask	Main	9.748 ns	0.1823 ns	1.00	72 B	1.00
Await_FromCompletedTask	PR	9.318 ns	0.1712 ns	0.96	72 B	1.00
Await_FromCompletedValueTaskSource	Main	15.410 ns	0.2158 ns	1.00	72 B	1.00
Await_FromCompletedValueTaskSource	PR	15.242 ns	0.1697 ns	0.99	72 B	1.00
CreateAndAwait_FromResult	Main	5.281 ns	0.0154 ns	1.00	-	NA
CreateAndAwait_FromResult	PR	5.294 ns	0.0182 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	Main	5.276 ns	0.0160 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	PR	5.312 ns	0.0280 ns	1.01	-	NA
CreateAndAwait_FromCompletedTask	Main	5.774 ns	0.0214 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask	PR	5.914 ns	0.0899 ns	1.02	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	Main	5.817 ns	0.0137 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	PR	6.211 ns	0.0136 ns	1.07	-	NA
CreateAndAwait_FromCompletedValueTaskSource	Main	6.762 ns	0.0108 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource	PR	6.319 ns	0.0094 ns	0.93	-	NA
CreateAndAwait_FromYieldingAsyncMethod	Main	204.260 ns	9.2949 ns	1.00	207 B	1.00
CreateAndAwait_FromYieldingAsyncMethod	PR	212.860 ns	13.1086 ns	1.04	207 B	1.00
CreateAndAwait_FromDelayedTCS	Main	77.672 ns	0.3388 ns	1.00	216 B	1.00
CreateAndAwait_FromDelayedTCS	PR	76.081 ns	0.5506 ns	0.98	216 B	1.00
Copy_PassAsArgumentAndReturn_FromResult	Main	2.842 ns	0.0268 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromResult	PR	2.832 ns	0.0272 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	Main	5.853 ns	0.0244 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	PR	6.085 ns	0.0314 ns	1.04	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	Main	8.025 ns	0.0529 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	PR	7.993 ns	0.0522 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	Main	6.334 ns	0.0582 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	PR	6.310 ns	0.0456 ns	1.00	-	NA

System.Threading.Channels.Tests.UnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	30.37 ns	0.041 ns	1.00	-	NA
TryWriteThenTryRead	PR	30.40 ns	0.034 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	30.35 ns	0.029 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	30.35 ns	0.019 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	49.04 ns	0.016 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	49.30 ns	0.207 ns	1.01	-	NA
PingPong	Main	2,627,902.03 ns	111,019.119 ns	1.00	903 B	1.00
PingPong	PR	2,658,820.31 ns	145,066.288 ns	1.01	901 B	1.00

System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	17.54 ns	0.013 ns	1.00	-	NA
TryWriteThenTryRead	PR	17.54 ns	0.010 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	22.39 ns	0.016 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	22.43 ns	0.025 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	46.94 ns	0.020 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	47.04 ns	0.076 ns	1.00	-	NA
PingPong	Main	2,511,563.26 ns	93,531.184 ns	1.00	901 B	1.00
PingPong	PR	2,627,531.08 ns	129,689.322 ns	1.05	900 B	1.00

System.Threading.Channels.Tests.BoundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	35.91 ns	0.031 ns	1.00	-	NA
TryWriteThenTryRead	PR	35.87 ns	0.019 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	37.57 ns	0.044 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	37.61 ns	0.061 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	47.84 ns	0.043 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	48.03 ns	0.038 ns	1.00	-	NA
PingPong	Main	2,893,666.76 ns	138,789.838 ns	1.00	901 B	1.00
PingPong	PR	2,847,279.72 ns	148,677.365 ns	0.99	901 B	1.00

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/ea54990edbbdbf16145eaa382580240f

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Calling it on every IO completion can become a noticeable CPU cost exactly when the pool is large. Consider enforcing MaxEventPoolCount with a separate Interlocked-updated counter (increment when returning an Event to the pool, decrement when renting) so the hot path avoids Count while still bounding growth.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Checking it on every SocketIOEvent.Execute() adds avoidable overhead on a very hot path and becomes more expensive as the pool grows. Consider tracking an explicit pool size counter (Interlocked) so MaxEventPoolCount can be enforced without calling Count per completion.

 if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[eduardo-vp]

LGTM!

[VSadov]

Thanks!

[VSadov]

To avoid allocating a workitem per every socket/IO event and reduce the number of enqueues to the global queue we use the following pattern:

• Socket/IO engine places the events (a struct) into a concurrent queue, where the storage is naturally reused.
• In order to get the event executed, we post a self-replicating workitem into a global queue and that workitem fetches the events and executes them.
• There is also a heuristic that if the queue runs dry or after some time duration (and in Windows case also in a presence of local workitems) the task stops "pumping" of the events would not starve other workitems.

=== The pattern has some issues that get worse on big core counts:

• The self-replication of the event queue task places copies of itself into the global queue every time a worker starts "pumping" and sees more items in the queue. We must do this for correctness - to make sure that remaining queued events will be eventually picked up even if the current thread blocks.
  This self-requeuing can put a lot of stress on the global queue.
  In a case of assignable queues, the re-queued item ends up in the assignable queue, which are local to a subset of workers, thus may impact p99 latencies.

• When a worker stops dispatching from the event queue (due to time limit, for example) and then picks up an event queue task again, it may be a queue from a different IO engine.
  This randomizes both the assignment of the event queues to workers and the order of event execution.
  It is possible that multiple workers would "pump" events from the same queue, while other queues are neglected (and keep growing if events are arriving).
  A queue that is overshared may cause contentions, spinning/sleeping of workers.

• the event queue is basically a memory cache with no upper bounds. We do not know how big the event queue can get if the enqueuing outruns dequeuing for some nontrivial time.
  We do not report the size of this queue in the ThreadPool Queue Length or any other counter even though these are technically threadpool workitems.

=== What we do instead in this PR:
At the high level instead of relying on a queue to reduce the number of global enqueues (temporal batching), we explicitly combine multiple events into batches of predictable and bounded size and enqueue entire batches to the global queue.

Details:

• IO engine fills actual event workitems (in IThreadPoolWorkItem sense) with data.

• The workitems are reused via a pool that has an upper bound.
  (in an unlikely case that the limit is reached we will allocate/GC the workitems).

• To avoid stressing the global queues, the workitems are packed into balanced binary trees, so that we could submit the entire batch for execution in one enqueue.

• Worker threads, upon executing the parent, place the children into the local queue.
  The current worker is likely still the best worker to execute the children, but if other workers need work they can steal whole subtrees thus divide-and-conquering the remaining work.

• as a general approach if execution of an event results in more than one task, we place the additional tasks into the local queue - to relieve the stress on the global queue, improve the locality of execution and statistically reduce the max workqueue lengths.

• the size of a batch is bounded to make sure that large batches do not impact p99 latency.

=== Perf diffs:

JSON benchmarks

 x64 / HIGH load (56 cores, load 4096 connections, load threads=64)
- base RPS 2,528,080 p50 1.47 ms p99 3.79 ms+ new RPS 2,580,722 p50 1.50 ms p99 3.13 ms
+2.1% +2.0% -17.4%
x64 / LOW load (56 cores, load 512 connections)
- base RPS 2,141,591 p50 0.21 ms p99 0.57 ms+ new RPS 2,177,068 p50 0.21 ms p99 0.59 ms
+1.7% 0.0% +3.5%
arm64 / HIGH load (96 cores, load 4096 connections, load threads=64)
- base RPS 3,715,921 p50 0.57 ms p99 7.30 ms+ new RPS 3,696,351 p50 0.56 ms p99 7.01 ms
-0.5% -1.8% -4.0%
arm64 / LOW load (96 cores, load 256 connections)
- base RPS 2,064,045 p50 0.25 ms p99 0.78 ms+ new RPS 2,149,487 p50 0.25 ms p99 0.44 ms
+4.1% 0.0% -43.6%

The change appears to erase most of the gap with net10 on JSON benchmark in high core configuration, thus:
Fixes: #127484

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR changes how socket / IO completion events are dispatched to the thread pool, replacing the prior “queue + pumping work item” pattern with pooled per-event work items that are submitted in batches via a balanced binary tree to reduce global-queue pressure and bound memory growth.

Changes:

• Remove the Windows-only ThreadPoolTypedWorkItemQueue sub-dispatcher from ThreadPoolWorkQueue.
• Windows IOCP: pool IOCompletionPoller.Event instances and batch-submit completions as a balanced tree, fanning out to local queues as nodes execute.
• Unix sockets: pool SocketIOEvent instances and similarly batch-submit async socket events as a balanced tree; adjust some preferLocal scheduling.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs	Removes the Windows-only typed work item queue implementation previously used for IO sub-dispatch.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs	Introduces pooled Event work items and balanced-tree batching for IOCP completions; changes queueing behavior.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs	Reworks async socket event dispatch to use pooled SocketIOEvent work items and balanced-tree batching.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs	Switches some thread-pool queueing to preferLocal: true for async operation processing/cancellation callbacks.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• Using ConcurrentQueue<T>.Count in the hot path (SocketIOEvent.Execute) can be quite expensive under contention (Count is not O(1) for ConcurrentQueue<T>). Since this runs per completion, it risks regressing throughput and adding cross-thread cache contention. Consider tracking pool size with an explicit int counter (Interlocked increment/decrement on enqueue/dequeue) instead of calling Count here.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• Using ConcurrentQueue<T>.Count in Event.Execute is a potentially expensive operation under contention (Count is not O(1) for ConcurrentQueue<T>). Since this executes per IO completion, it can add avoidable overhead. Consider tracking pool size with an explicit Interlocked counter on borrow/return instead of querying Count here.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:394

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it for every completion work item defeats some of the intended perf/throughput wins.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:377

• ConcurrentQueue<T>.Count can be relatively expensive under contention (it may spin and can take the cross-segment lock when multiple segments are present; see ConcurrentQueue<T>.Count implementation). Calling it on every async socket event adds overhead on the hot path.

Consider tracking an approximate pool size with an int updated via Interlocked alongside the queue, and using that for the max-pool bound check instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:102

• The comment above _eventQueue says it’s a queue of events generated by EventLoop, but in this revision _eventQueue is used as a pool of reusable SocketIOEvent instances (see RentEvent and SocketIOEvent.Execute). Updating the comment would prevent future confusion about its semantics and why it’s bounded.

 //
// Queue of events generated by EventLoop() that would be processed by the thread pool
//
private readonly ConcurrentQueue<SocketIOEvent> _eventQueue = new ConcurrentQueue<SocketIOEvent>();

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:512

• Event pooling uses ConcurrentQueue.Count on every completion to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock (see ConcurrentQueue.cs), so calling it in this hot path can add contention/latency and offset the intended allocation savings. Consider using an Interlocked-based approximate pool size counter (increment on Enqueue, decrement on Dequeue) instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:527

• SocketIOEvent pooling uses ConcurrentQueue.Count on every event execution to enforce MaxEventPoolCount. ConcurrentQueue.Count can spin and may take the cross-segment lock, so this can be a measurable hot-path cost under high IO rates. Consider tracking pool size via an Interlocked counter (increment on Enqueue, decrement on RentEvent dequeue success) instead of Count.

 if (_queue.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_queue.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:509

• Using ConcurrentQueue.Count on every IO completion to enforce the pool bound is potentially expensive. ConcurrentQueue.Count can spin and may take _crossSegmentLock when there are multiple segments (see System.Collections.Concurrent.ConcurrentQueue.Count implementation), which can become a noticeable overhead at high IO rates. Consider tracking pool size with an Interlocked counter (increment on Enqueue, decrement on successful TryDequeue) to keep the bound check O(1) without extra locking.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:533

• SocketIOEvent.Execute() uses ConcurrentQueue.Count to enforce the pool bound. ConcurrentQueue.Count can spin and may take the cross-segment lock when multiple segments exist, so doing this per event can add measurable overhead under heavy IO. Consider maintaining an Interlocked pool-size counter instead of calling Count in the hot path.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue<T>.Count can take _crossSegmentLock (and spin/retry) when the queue has multiple segments, so calling _pool.Count on every completion is a potentially expensive hot-path operation and undermines the goal of reducing overhead. Consider tracking the pool size with an int updated via Interlocked on enqueue/dequeue (best-effort is fine) and use that value for the MaxEventPoolCount check instead of Count.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• _pool.Count is queried for every SocketIOEvent execution. ConcurrentQueue<T>.Count is not a cheap counter; it may spin and can take _crossSegmentLock when multiple segments exist, so this can become a measurable overhead under high event rates. Consider maintaining an int pool size updated via Interlocked on enqueue/dequeue and using that for the MaxEventPoolCount gate instead of Count.

 SocketAsyncContext context = _context!;
Interop.Sys.SocketEvents events = _events;
if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[VSadov]

@MihuBot benchmark System.Threading

[VSadov]

@MihuBot benchmark System.Buffers

[MihuBot]

System.Threading.Tests.Perf_Volatile

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Write_double	Main	0.9338 ns	0.0040 ns	1.00	-	NA
Write_double	PR	0.9317 ns	0.0029 ns	1.00	-	NA
Read_double	Main	0.9485 ns	0.0045 ns	1.00	-	NA
Read_double	PR	0.9459 ns	0.0064 ns	1.00	-	NA

System.Threading.Tests.Perf_Timer

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ShortScheduleAndDispose	Main	74.99 ns	0.395 ns	1.00	120 B	1.00
ShortScheduleAndDispose	PR	75.45 ns	0.697 ns	1.01	120 B	1.00
LongScheduleAndDispose	Main	75.44 ns	0.651 ns	1.00	120 B	1.00
LongScheduleAndDispose	PR	75.34 ns	0.673 ns	1.00	120 B	1.00
ScheduleManyThenDisposeMany	Main	223,379,838.13 ns	1,965,673.532 ns	1.00	144001328 B	1.00
ScheduleManyThenDisposeMany	PR	223,129,600.73 ns	2,591,171.964 ns	1.00	144001328 B	1.00
ShortScheduleAndDisposeWithFiringTimers	Main	80.28 ns	1.599 ns	1.00	144 B	1.00
ShortScheduleAndDisposeWithFiringTimers	PR	80.46 ns	1.515 ns	1.00	144 B	1.00
SynchronousContention	Main	1,420,584,665.07 ns	17,411,095.255 ns	1.00	1152000760 B	1.00
SynchronousContention	PR	1,298,023,677.18 ns	25,870,105.978 ns	0.91	1152000760 B	1.00
AsynchronousContention	Main	1,128,918,393.85 ns	36,890,792.880 ns	1.00	1152002232 B	1.00
AsynchronousContention	PR	1,403,692,668.40 ns	41,823,779.338 ns	1.25	1152002232 B	1.00

System.Threading.Tests.Perf_ThreadStatic

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
GetThreadStatic	Main	1.869 ns	0.0084 ns	1.00	-	NA
GetThreadStatic	PR	1.886 ns	0.0068 ns	1.01	-	NA
SetThreadStatic	Main	3.271 ns	0.0107 ns	1.00	-	NA
SetThreadStatic	PR	3.272 ns	0.0150 ns	1.00	-	NA

System.Threading.Tests.Perf_ThreadPool

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1 Gen0=38000.0000

Method	Toolchain	WorkItemsPerCore	Mean	Error	Ratio	Allocated	Alloc Ratio
QueueUserWorkItem_WaitCallback_Throughput	Main	20000000	1.980 s	0.0144 s	1.00	610.35 MB	1.00
QueueUserWorkItem_WaitCallback_Throughput	PR	20000000	1.965 s	0.0112 s	0.99	610.35 MB	1.00

System.Threading.Tests.Perf_Thread

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
CurrentThread	Main	1.895 ns	0.0140 ns	1.00	-	NA
CurrentThread	PR	1.892 ns	0.0078 ns	1.00	-	NA
GetCurrentProcessorId	Main	2.321 ns	0.0074 ns	1.00	-	NA
GetCurrentProcessorId	PR	2.119 ns	0.0111 ns	0.91	-	NA

System.Threading.Tests.Perf_SpinLock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	10.560 ns	0.0062 ns	1.00	-	NA
EnterExit	PR	10.553 ns	0.0124 ns	1.00	-	NA
TryEnterExit	Main	10.564 ns	0.0055 ns	1.00	-	NA
TryEnterExit	PR	10.546 ns	0.0044 ns	1.00	-	NA
TryEnter_Fail	Main	1.236 ns	0.0054 ns	1.00	-	NA
TryEnter_Fail	PR	1.233 ns	0.0050 ns	1.00	-	NA

System.Threading.Tests.Perf_SemaphoreSlim

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReleaseWait	Main	29.63 ns	0.016 ns	1.00	-	NA
ReleaseWait	PR	29.65 ns	0.014 ns	1.00	-	NA
ReleaseWaitAsync	Main	28.25 ns	0.021 ns	1.00	-	NA
ReleaseWaitAsync	PR	28.26 ns	0.011 ns	1.00	-	NA
ReleaseWaitAsync_WithCancellationToken	Main	317.66 ns	20.687 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithCancellationToken	PR	317.60 ns	22.628 ns	1.00	528 B	1.00
ReleaseWaitAsync_WithTimeout	Main	337.80 ns	17.205 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithTimeout	PR	318.12 ns	7.530 ns	0.94	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	Main	361.32 ns	11.905 ns	1.00	624 B	1.00
ReleaseWaitAsync_WithCancellationTokenAndTimeout	PR	362.21 ns	17.881 ns	1.00	624 B	1.00

System.Threading.Tests.Perf_Monitor

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EnterExit	Main	13.55 ns	0.008 ns	1.00	-	NA
EnterExit	PR	13.55 ns	0.006 ns	1.00	-	NA
TryEnterExit	Main	13.55 ns	0.009 ns	1.00	-	NA
TryEnterExit	PR	13.54 ns	0.007 ns	1.00	-	NA

System.Threading.Tests.Perf_Lock

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
ReaderWriterLockSlimPerf	Main	13.55 ns	0.008 ns	1.00	-	NA
ReaderWriterLockSlimPerf	PR	13.55 ns	0.034 ns	1.00	-	NA

System.Threading.Tests.Perf_Interlocked

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Increment_int	Main	4.824 ns	0.0021 ns	1.00	-	NA
Increment_int	PR	4.820 ns	0.0040 ns	1.00	-	NA
Decrement_int	Main	4.829 ns	0.0159 ns	1.00	-	NA
Decrement_int	PR	4.819 ns	0.0018 ns	1.00	-	NA
Increment_long	Main	4.818 ns	0.0025 ns	1.00	-	NA
Increment_long	PR	4.820 ns	0.0016 ns	1.00	-	NA
Decrement_long	Main	4.815 ns	0.0020 ns	1.00	-	NA
Decrement_long	PR	4.820 ns	0.0025 ns	1.00	-	NA
Add_int	Main	4.815 ns	0.0016 ns	1.00	-	NA
Add_int	PR	4.816 ns	0.0022 ns	1.00	-	NA
Add_long	Main	4.817 ns	0.0019 ns	1.00	-	NA
Add_long	PR	4.819 ns	0.0019 ns	1.00	-	NA
Exchange_int	Main	4.819 ns	0.0033 ns	1.00	-	NA
Exchange_int	PR	4.819 ns	0.0048 ns	1.00	-	NA
Exchange_long	Main	4.817 ns	0.0020 ns	1.00	-	NA
Exchange_long	PR	4.820 ns	0.0020 ns	1.00	-	NA
CompareExchange_int	Main	4.829 ns	0.0024 ns	1.00	-	NA
CompareExchange_int	PR	4.830 ns	0.0019 ns	1.00	-	NA
CompareExchange_long	Main	4.832 ns	0.0037 ns	1.00	-	NA
CompareExchange_long	PR	4.831 ns	0.0033 ns	1.00	-	NA
CompareExchange_object_Match	Main	5.509 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_Match	PR	5.508 ns	0.0035 ns	1.00	-	NA
CompareExchange_object_NoMatch	Main	5.510 ns	0.0028 ns	1.00	-	NA
CompareExchange_object_NoMatch	PR	5.508 ns	0.0041 ns	1.00	-	NA

System.Threading.Tests.Perf_EventWaitHandle

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Set_Reset	Main	42.75 ns	0.027 ns	1.00	-	NA
Set_Reset	PR	42.72 ns	0.020 ns	1.00	-	NA

System.Threading.Tests.Perf_CancellationToken

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NRQIIJ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-NGSIDY : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
RegisterAndUnregister_Serial	Main	18.912 ns	0.0493 ns	1.00	-	NA
RegisterAndUnregister_Serial	PR	18.946 ns	0.1112 ns	1.00	-	NA
Cancel	Main	54.448 ns	0.8583 ns	1.00	192 B	1.00
Cancel	PR	53.189 ns	0.3285 ns	0.98	192 B	1.00
CreateLinkedTokenSource1	Main	21.830 ns	0.3112 ns	1.00	64 B	1.00
CreateLinkedTokenSource1	PR	21.034 ns	0.4128 ns	0.96	64 B	1.00
CreateLinkedTokenSource2	Main	38.236 ns	0.4997 ns	1.00	80 B	1.00
CreateLinkedTokenSource2	PR	37.323 ns	0.1491 ns	0.98	80 B	1.00
CreateLinkedTokenSource3	Main	58.207 ns	0.3793 ns	1.00	128 B	1.00
CreateLinkedTokenSource3	PR	58.819 ns	0.3601 ns	1.01	128 B	1.00
CreateTokenDispose	Main	5.448 ns	0.0367 ns	1.00	48 B	1.00
CreateTokenDispose	PR	5.462 ns	0.0467 ns	1.00	48 B	1.00
CreateRegisterDispose	Main	32.044 ns	0.3211 ns	1.00	192 B	1.00
CreateRegisterDispose	PR	31.946 ns	0.3375 ns	1.00	192 B	1.00
CreateManyRegisterDispose	Main	14.507 ns	0.0215 ns	1.00	-	NA
CreateManyRegisterDispose	PR	14.487 ns	0.0178 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	Main	80.629 ns	0.1873 ns	1.00	-	NA
CreateManyRegisterMultipleDispose	PR	81.699 ns	0.1683 ns	1.01	-	NA
CancelAfter	Main	51.286 ns	0.3029 ns	1.00	144 B	1.00
CancelAfter	PR	52.058 ns	1.7330 ns	1.02	144 B	1.00

System.Threading.Tasks.Tests.Perf_AsyncMethods

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
EmptyAsyncMethodInvocation	Main	3.731 ns	0.0128 ns	1.00	-	NA
EmptyAsyncMethodInvocation	PR	3.286 ns	0.0038 ns	0.88	-	NA
SingleYieldMethodInvocation	Main	102.221 ns	5.3328 ns	1.00	96 B	1.00
SingleYieldMethodInvocation	PR	100.185 ns	4.8837 ns	0.98	96 B	1.00
Yield	Main	30.483 ns	0.5967 ns	1.00	-	NA
Yield	PR	30.693 ns	1.1908 ns	1.01	-	NA

System.Threading.Tasks.ValueTaskPerfTest

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-UXTJFQ : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-WCARJH : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-XVCCJK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HMQJNI : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False PowerPlanMode= IterationTime=250ms
MaxIterationCount=20 MaxWarmupIterationCount=10 MinIterationCount=15
MinWarmupIterationCount=2 WarmupCount=-1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
Await_FromResult	Main	5.328 ns	0.0110 ns	1.00	-	NA
Await_FromResult	PR	5.446 ns	0.0079 ns	1.02	-	NA
Await_FromCompletedTask	Main	9.748 ns	0.1823 ns	1.00	72 B	1.00
Await_FromCompletedTask	PR	9.318 ns	0.1712 ns	0.96	72 B	1.00
Await_FromCompletedValueTaskSource	Main	15.410 ns	0.2158 ns	1.00	72 B	1.00
Await_FromCompletedValueTaskSource	PR	15.242 ns	0.1697 ns	0.99	72 B	1.00
CreateAndAwait_FromResult	Main	5.281 ns	0.0154 ns	1.00	-	NA
CreateAndAwait_FromResult	PR	5.294 ns	0.0182 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	Main	5.276 ns	0.0160 ns	1.00	-	NA
CreateAndAwait_FromResult_ConfigureAwait	PR	5.312 ns	0.0280 ns	1.01	-	NA
CreateAndAwait_FromCompletedTask	Main	5.774 ns	0.0214 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask	PR	5.914 ns	0.0899 ns	1.02	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	Main	5.817 ns	0.0137 ns	1.00	-	NA
CreateAndAwait_FromCompletedTask_ConfigureAwait	PR	6.211 ns	0.0136 ns	1.07	-	NA
CreateAndAwait_FromCompletedValueTaskSource	Main	6.762 ns	0.0108 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource	PR	6.319 ns	0.0094 ns	0.93	-	NA
CreateAndAwait_FromYieldingAsyncMethod	Main	204.260 ns	9.2949 ns	1.00	207 B	1.00
CreateAndAwait_FromYieldingAsyncMethod	PR	212.860 ns	13.1086 ns	1.04	207 B	1.00
CreateAndAwait_FromDelayedTCS	Main	77.672 ns	0.3388 ns	1.00	216 B	1.00
CreateAndAwait_FromDelayedTCS	PR	76.081 ns	0.5506 ns	0.98	216 B	1.00
Copy_PassAsArgumentAndReturn_FromResult	Main	2.842 ns	0.0268 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromResult	PR	2.832 ns	0.0272 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	Main	5.853 ns	0.0244 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromTask	PR	6.085 ns	0.0314 ns	1.04	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	Main	8.025 ns	0.0529 ns	1.00	-	NA
Copy_PassAsArgumentAndReturn_FromValueTaskSource	PR	7.993 ns	0.0522 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	Main	6.334 ns	0.0582 ns	1.00	-	NA
CreateAndAwait_FromCompletedValueTaskSource_ConfigureAwait	PR	6.310 ns	0.0456 ns	1.00	-	NA

System.Threading.Channels.Tests.UnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	30.37 ns	0.041 ns	1.00	-	NA
TryWriteThenTryRead	PR	30.40 ns	0.034 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	30.35 ns	0.029 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	30.35 ns	0.019 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	49.04 ns	0.016 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	49.30 ns	0.207 ns	1.01	-	NA
PingPong	Main	2,627,902.03 ns	111,019.119 ns	1.00	903 B	1.00
PingPong	PR	2,658,820.31 ns	145,066.288 ns	1.01	901 B	1.00

System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	17.54 ns	0.013 ns	1.00	-	NA
TryWriteThenTryRead	PR	17.54 ns	0.010 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	22.39 ns	0.016 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	22.43 ns	0.025 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	46.94 ns	0.020 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	47.04 ns	0.076 ns	1.00	-	NA
PingPong	Main	2,511,563.26 ns	93,531.184 ns	1.00	901 B	1.00
PingPong	PR	2,627,531.08 ns	129,689.322 ns	1.05	900 B	1.00

System.Threading.Channels.Tests.BoundedChannelPerfTests

BenchmarkDotNet v0.16.0-nightly.20260703.576, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
AMD EPYC 9V45 2.60GHz, 1 CPU, 8 logical and 4 physical cores
Memory: 31.34 GB Total, 5.59 GB Available
Job-TPEJOW : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
Job-HKHXHK : .NET 11.0.0 (11.0.0-dev, 42.42.42.42424), X64 RyuJIT x86-64-v4
EvaluateOverhead=False OutlierMode=Default PowerPlanMode=
IterationTime=250ms MaxIterationCount=20 MemoryRandomization=Default
MinIterationCount=15 WarmupCount=1

Method	Toolchain	Mean	Error	Ratio	Allocated	Alloc Ratio
TryWriteThenTryRead	Main	35.91 ns	0.031 ns	1.00	-	NA
TryWriteThenTryRead	PR	35.87 ns	0.019 ns	1.00	-	NA
WriteAsyncThenReadAsync	Main	37.57 ns	0.044 ns	1.00	-	NA
WriteAsyncThenReadAsync	PR	37.61 ns	0.061 ns	1.00	-	NA
ReadAsyncThenWriteAsync	Main	47.84 ns	0.043 ns	1.00	-	NA
ReadAsyncThenWriteAsync	PR	48.03 ns	0.038 ns	1.00	-	NA
PingPong	Main	2,893,666.76 ns	138,789.838 ns	1.00	901 B	1.00
PingPong	PR	2,847,279.72 ns	148,677.365 ns	0.99	901 B	1.00

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/ea54990edbbdbf16145eaa382580240f

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs:408

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Calling it on every IO completion can become a noticeable CPU cost exactly when the pool is large. Consider enforcing MaxEventPoolCount with a separate Interlocked-updated counter (increment when returning an Event to the pool, decrement when renting) so the hot path avoids Count while still bounding growth.

 if (_pool.Count < MaxEventPoolCount)
{
this.nativeOverlapped = null;
this.bytesTransferred = 0;
_left = null;
_right = null;
_pool.Enqueue(this);
}

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:421

• ConcurrentQueue.Count is not a cheap constant-time read (it may spin and can take the cross-segment lock when the queue spans multiple segments). Checking it on every SocketIOEvent.Execute() adds avoidable overhead on a very hot path and becomes more expensive as the pool grows. Consider tracking an explicit pool size counter (Interlocked) so MaxEventPoolCount can be enforced without calling Count per completion.

 if (_pool.Count < MaxEventPoolCount)
{
_context = null;
_events = Interop.Sys.SocketEvents.None;
_left = null;
_right = null;
_pool.Enqueue(this);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[eduardo-vp]

LGTM!

[VSadov]

Thanks!