blob: cdc74e66bcb421303d801e99804340060692b350 [file] [log] [blame]
- The consumer code needs a much cleaner abstraction
In the end, it's two-phase, e.g. receive message, ack message, perhaps we make this a
first-class citizen in the API on the consumer side where the consumer calls:
Receive() and gets the sequence of the message in question (or a specific value for
gating/idling?) and then calls Ack/Confirm etc with the message sequence?
- Wireup DSL
- Rewrite code test first
- Verify "diamond" consumer pattern (with tests)
- Benchmark code (go test -bench=.) (with GOMAXPROCS=2 if env GOMAXPROCS=1)
- MultiWriter (and appropriate hooks into Barrier)
- Squeeze little bits of performance here and there by trying a few different things
e.g. pointers vs structs, padding, etc.
- Investigate ways to utilize an int32 under the hood but have it be exposed as an int64?
e.g. utilizing two int32s? This would allow us to remove the atomic statements surrounding
i386 and ARM architecutes, but may be more effort than it's worth for our particular
use case...
- Understand why "slower" consumer code is faster and more consistent when performing single-item
- I need to get some help doing some low-level profiling the application to find out where
the bottlenecks are and determining how the Go scheduler is hindering performance, if at all.
- contributors
- license
- readme (Github markdown?)
- Website with cool images and documentation? (e.g. GoConvey)