feat: Support Monotonic UUIDv7 Batch Generation#191
Conversation
dylan-bourque
left a comment
dylan-bourque
left a comment
There was a problem hiding this comment.
This feels like a lot of added complexity to be able to generate more than one V7 UUID at a time.
| // | ||
| // Returns: | ||
| // - GenOption: A function to configure the generator. | ||
| func WithCustomPRNG(seed int64) GenOption { |
There was a problem hiding this comment.
Assuming we move forward I think this function should be called WithExplicitRandSeed(), or something similar, to better reflect what it's actually doing.
| // | ||
| // MonotonicGen ensures the generation of strictly monotonic UUIDs within a | ||
| // batch by utilizing a counter in conjunction with timestamps. This is | ||
| // particularly useful for applications requiring ordered identifiers, such |
There was a problem hiding this comment.
for applications requiring ordered identifiers
v6 and v7 UUIDs are already ordered so none of this is strictly necessary except to enable batch generation, and I'm not sold on the utility there. I have used this library to generate UUIDs on the order of tens of millions per second sustained over 1000s of nodes in a distributed system without ever running into a scenario where I wanted/needed to pre-allocate a block of values.
There was a problem hiding this comment.
I agree with @dylan-bourque - I'm really not sure how useful this is relative to the increased complexity. I haven't generated millions per second, but I can't see any reason that the existing implementation doesn't do what you want. Moreover, I'm concerned that having two separate implementations of generating a new UUIDv7 (the existing public method for generating one at a time and your new private method that is called in the loop) will lead to maintenance headaches.
Is there a specific situation you have encountered in which the existing implementation fails to provide monotonically increasing values? If there is, please explain in more detail to help us understand the need.
|
I did some benchmarking (but not independent testing for validation): Looks like the batch generation is about 3.777 milliseconds faster for one million UUIDs, but about 16 megabytes more memory usage and one more alloc. (Of course that's my environment, YMMV.) Unless my benchmarks have bugs (please validate), this is a lot of code maintenance for that small of an improvement IMHO. Batch sizes of 100 UUIDs give the batch method proposed about 177 nanoseconds of an advantage, with a similar doubling of memory usage. Benchmark code used: var uuidsBenchmarkSink []UUID
func BenchmarkGenerateBatchV7(b *testing.B) {
b.ReportAllocs()
gen := NewMonotonicGen()
batchSize := 1000000
var err error
b.ResetTimer()
for i := 0; i < b.N; i++ {
uuidsBenchmarkSink, err = gen.GenerateBatchV7(batchSize)
if err != nil {
b.Fatalf("Error generating batch: %v", err)
}
}
}
func BenchmarkGenerateWithoutBatchV7(b *testing.B) {
b.ReportAllocs()
batchSize := 1000000
uuidsBenchmarkSink = make([]UUID, batchSize, batchSize)
var err error
b.ResetTimer()
for i := 0; i < b.N; i++ {
for j := 0; j < batchSize; j++ {
uuidsBenchmarkSink[j], err = NewV7()
if err != nil {
b.Fatalf("error generating UUID: %v", err)
}
}
}
} |
|
Hi, it's been a while since this was opened. We do appreciate the contribution, but the consensus among the maintainers seems to be that this isn't something we want to include in the library. Thank you. I hope this doesn't dissuade you from contributing another change. |
5 participants
Changes
This PR introduces a new feature for monotonic
UUIDv7batch generation including;GenerateBatchV7method in a newMonotonicGenstruct for batch generation.WithCustomPRNGoption for deterministic UUID generation.BY aligning with the existing library structure; this PR proposes enhanced functionality for users requiring batch UUID generation while maintaining compatibility with RFC Spec. Feedback welcome!