4 ms·
It could be that this design covers this as well - but one thing worth calling out explicitly is the effects that message passing can have on GC. If you spend
by jakewins 10y ago
It could be that this design covers this as well - but one thing worth calling out explicitly is the effects that message passing can have on GC.
If you spend tons of effort making your queues low contention and super low latency, you best make sure the API you give the user doesn't then undo all that fine engineering by overloading the GC by allocating a million messages a second.
Shameless plug, in that I tried to address that in 4fq by having the queue own the memory for messages. The main job of the queue then being to arbitrate who controls which message slots in RAM:
https://github.com/jakewins/4fq https://github.com/jakewins/4fq
- infogulch 10y agoGo's channels take a copy of the value you pass to it. Now, if you pass pointers or interfaces, of course you'll have allocations. But it's entirely possible for two goroutines to communicate over a channel and produce zero allocations, where values put into and taken out of the channel are stored exclusively on the stack.