Benchmarks

These numbers measure the pool alone: a job is an int and the workers do nothing with it, so what’s left is the cost of queueing a job and handing it to a worker. Your jobs will dominate a real run; the point is that the pool adds as little as possible.

Delegate alone runs into a queue with room for every job. A job through workers runs through a queue of 1024: when the workers fall behind, Delegate waits, so the time per job is the pace of the whole pool. With 16 callers at once, the time is wall time per call across all of them, so it measures throughput.

v3 against v2

Both versions ran on the same harness, with the same jobs.

Jobs

Time per job, from Delegate to the worker, lower is better

• v2
• v3

1 worker5.6× faster

215.9 ns

38.8 ns

16 workers3.7× faster

412.1 ns

110.1 ns

1 worker, 16 callers at once4.3× faster

372.3 ns

86.9 ns

16 workers, 16 callers at once4.7× faster

258.3 ns

55.4 ns

Show as a table

Time per job, from Delegate to the worker: time and allocations, v2 against v3

Scenario	v2	v3
1 worker	215.9 ns2 allocs	38.8 ns0 allocs
16 workers	412.1 ns2 allocs	110.1 ns0 allocs
1 worker, 16 callers at once	372.3 ns2 allocs	86.9 ns0 allocs
16 workers, 16 callers at once	258.3 ns2 allocs	55.4 ns0 allocs

Apple M4 Max, Go 1.27.0, median of 5 runs.

Delegate

Time per call to Delegate, lower is better

• v2
• v3

queue has room2.9× faster

32.6 ns

11.4 ns

queue has room, 16 callers at once2.4× faster

86.0 ns

35.4 ns

Show as a table

Time per call to Delegate: time and allocations, v2 against v3

Scenario	v2	v3
queue has room	32.6 ns2 allocs	11.4 ns0 allocs
queue has room, 16 callers at once	86.0 ns2 allocs	35.4 ns0 allocs

Apple M4 Max, Go 1.27.0, median of 5 runs.

v2 built a slice of reflect.Values for every job, boxing each argument, and called the worker with reflect.Value.Call. v3 sends the job on a typed channel and calls the worker’s func directly.

With jobs that do nothing, one caller can’t keep 16 workers busy: they wait and wake for every job, which costs more than the job itself. With real work, the workers stay busy and take jobs straight from the queue.

v3’s own suite

Benchmark	Time	Memory	Allocations
DelegateInto a queue with room, no worker	11.0 ns	0 B	0
Job/workers=1One caller, one worker, a queue of 1024	38.0 ns	0 B	0
Job/workers=16One caller, sixteen workers	104.1 ns	0 B	0
JobParallelSixteen callers, sixteen workers	46.2 ns	0 B	0

Where the time goes

Delegate checks the context, takes a read lock that orders it against Stop, and sends on a channel. A worker checks whether it was removed, which takes no lock, and receives from the channel; only when the queue is empty does it wait on both the queue and its quit channel. Neither allocates. Adding a worker allocates the worker, its quit channel, its goroutine’s closure and the remove func it returns.

Run them yourself

From a clone of the repository:

go test -run '^$' -bench . -benchmem

To compare two versions, run each a few times and compare with benchstat:

go test -run '^$' -bench . -count 10 > new.txt
benchstat old.txt new.txt

The allocation counts are also enforced by tests: TestAllocations fails if a call allocates more than it should.