一个线程安全的队列,比golang的原生通道更快速、更节省资源
A low-latency thread-safe queue in golang implemented using a lock-free ringbuffer and runtime internals
Based on the LMAX Disruptor Pattern
time/opmemory_allocation/op and num_allocations/op evident while benchmarking large batch size inputsselect{} ensuring fair selection and no starvationBenchmarks to support the above claims here
You need Golang 1.19.x or above
$ go get github.com/alphadose/zenq/v2package main
import (
"fmt"
"github.com/alphadose/zenq/v2"
)
type payload struct {
alpha int
beta string
}
func main() {
zq := zenq.New[payload](10)
for j := 0; j The number of goroutines concurrently writing to ZenQ/Channel
* INPUT_SIZE -> The number of input payloads to be passed through ZenQ/Channel from producers to consumer
```bash
Computed from benchstat of 30 benchmarks each via go test -benchmem -bench=. benchmarks/simple/*.go
name time/op
_Chan_NumWriters1_InputSize600-8 23.2µs ± 1%
_ZenQ_NumWriters1_InputSize600-8 17.9µs ± 1%
_Chan_NumWriters3_InputSize60000-8 5.27ms ± 3%
_ZenQ_NumWriters3_InputSize60000-8 2.36ms ± 2%
_Chan_NumWriters8_InputSize6000000-8 671ms ± 2%
_ZenQ_NumWriters8_InputSize6000000-8 234ms ± 6%
_Chan_NumWriters100_InputSize6000000-8 1.59s ± 4%
_ZenQ_NumWriters100_InputSize6000000-8 309ms ± 2%
_Chan_NumWriters1000_InputSize7000000-8 1.97s ± 0%
_ZenQ_NumWriters1000_InputSize7000000-8 389ms ± 4%
_Chan_Million_Blocking_Writers-8 10.4s ± 2%
_ZenQ_Million_Blocking_Writers-8 2.32s ±21%
name alloc/op
_Chan_NumWriters1_InputSize600-8 0.00B
_ZenQ_NumWriters1_InputSize600-8 0.00B
_Chan_NumWriters3_InputSize60000-8 109B ±68%
_ZenQ_NumWriters3_InputSize60000-8 24.6B ±107%
_Chan_NumWriters8_InputSize6000000-8 802B ±241%
_ZenQ_NumWriters8_InputSize6000000-8 1.18kB ±100%
_Chan_NumWriters100_InputSize6000000-8 44.2kB ±41%
_ZenQ_NumWriters100_InputSize6000000-8 10.7kB ±38%
_Chan_NumWriters1000_InputSize7000000-8 476kB ± 8%
_ZenQ_NumWriters1000_InputSize7000000-8 90.6kB ±10%
_Chan_Million_Blocking_Writers-8 553MB ± 0%
_ZenQ_Million_Blocking_Writers-8 122MB ± 3%
name allocs/op
_Chan_NumWriters1_InputSize600-8 0.00
_ZenQ_NumWriters1_InputSize600-8 0.00
_Chan_NumWriters3_InputSize60000-8 0.00
_ZenQ_NumWriters3_InputSize60000-8 0.00
_Chan_NumWriters8_InputSize6000000-8 2.76 ±190%
_ZenQ_NumWriters8_InputSize6000000-8 5.47 ±83%
_Chan_NumWriters100_InputSize6000000-8 159 ±26%
_ZenQ_NumWriters100_InputSize6000000-8 25.1 ±39%
_Chan_NumWriters1000_InputSize7000000-8 1.76k ± 6%
_ZenQ_NumWriters1000_InputSize7000000-8 47.3 ±31%
_Chan_Million_Blocking_Writers-8 2.00M ± 0%
_ZenQ_Million_Blocking_Writers-8 1.00M ± 0%The above results show that ZenQ is more efficient than channels in all 3 metrics i.e time/op, mem_alloc/op and num_allocs/op for the following tested cases:-
In SPSC mode ZenQ is faster than channels by 92 seconds in case of input size of 6 * 108 elements
❯ go run benchmarks/simple/main.go
With Input Batch Size: 60 and Num Concurrent Writers: 1
Native Channel Runner completed transfer in: 26.916µs
ZenQ Runner completed transfer in: 20.292µs
====================================================================
With Input Batch Size: 600 and Num Concurrent Writers: 1
Native Channel Runner completed transfer in: 135.75µs
ZenQ Runner completed transfer in: 105.792µs
====================================================================
With Input Batch Size: 6000 and Num Concurrent Writers: 1
Native Channel Runner completed transfer in: 2.100209ms
ZenQ Runner completed transfer in: 510.792µs
====================================================================
With Input Batch Size: 6000000 and Num Concurrent Writers: 1
Native Channel Runner completed transfer in: 1.241481917s
ZenQ Runner completed transfer in: 226.068209ms
====================================================================
With Input Batch Size: 600000000 and Num Concurrent Writers: 1
Native Channel Runner completed transfer in: 1m55.074638875s
ZenQ Runner completed transfer in: 22.582667917s
====================================================================暂无开放 Issues,或尚未同步最近议题。