Closed KodrAus closed 4 months ago
I've got a counter implemented, but looks like performance here could use some improvement compared to uuid7
:
running 2 tests
test new_v4 ... bench: 24.69 ns/iter (+/- 0.43)
test uuid7_v4 ... bench: 14.31 ns/iter (+/- 0.06)
test now_v7 ... bench: 56.86 ns/iter (+/- 1.04)
test uuid7_v7 ... bench: 38.03 ns/iter (+/- 0.59)
Ok, I think that's better now:
test new_v4 ... bench: 8.35 ns/iter (+/- 0.34)
test uuid7_v4 ... bench: 14.38 ns/iter (+/- 0.78)
test now_v7 ... bench: 36.51 ns/iter (+/- 2.60)
test uuid7_v7 ... bench: 38.31 ns/iter (+/- 2.35)
I need to add some tests for the new v7 context, and make sure we're shifting it around the variant field correctly.
For #717
This PR sketches out a solution to make the v7 support respect the input counter, while retaining existing semantics around filling with random data. It requires a bit of fudgery to keep compatibility with existing APIs, but I think the overall solution works out ok. I need to actually fill it all in fully and then explore ways to better integrate the existing
Timestamp
API, which may involve deprecating bits.The gist of it is to add a
usable_bits
method toClockSequence
, so it can tell how many bits a given counter occupies. The UUID constructor can then do appropriate shifts and fill the rest with random bytes. That way a caller creating a v7 UUID can decide how many bits to dedicate to sequencing and how many to randomness.As part of this PR I'm expecting to find some solution to re-seeding sequences, which will probably remain an implementation detail of the given
ClockSequence
.