Closed XAMPPRocky closed 10 months ago
I think the test vectors (appendix A) changed for one of the new versions at some point.
Oh well spotted. It looks like the v6
vector changed. I think I prefer our current test case where the timestamps in v1
and v6
are the same so you can see how the same timestamp encodes differently. As far as I can tell the way we encode v6
timestamps is still correct, but is the sort of thing that would be great to get a second opinion on before we ship 🙂
I'm not sure where benchmarks are used, but one for v7 would be interesting to see how it compares to v4
In my stabilization PR I added a benchmark you can run to evaluate the impact of switching from v4
to v7
. For what it's worth, on my Windows desktop here I'm currently seeing results like:
test new_v4 ... bench: 28 ns/iter (+/- 1)
test now_v7 ... bench: 47 ns/iter (+/- 1)
I think the test vectors (appendix A) changed for one of the new versions at some point.
Oh well spotted. It looks like the
v6
vector changed. I think I prefer our current test case where the timestamps inv1
andv6
are the same so you can see how the same timestamp encodes differently. As far as I can tell the way we encodev6
timestamps is still correct, but is the sort of thing that would be great to get a second opinion on before we ship 🙂
It looks correct to my eyes. But maybe it would be good to just add a test with the exact v6 and v7 examples from the RFC as a sanity check?
I'm not sure where benchmarks are used, but one for v7 would be interesting to see how it compares to v4
In my stabilization PR I added a benchmark you can run to evaluate the impact of switching from
v4
tov7
. For what it's worth, on my Windows desktop here I'm currently seeing results like:test new_v4 ... bench: 28 ns/iter (+/- 1) test now_v7 ... bench: 47 ns/iter (+/- 1)
🤦 I was thinking the existing benchmark was for v1 and not v4, couldn't figure out why the difference was so large. Thanks for the results!
Is your feature request related to a problem? Please describe. There is a new draft RFC for UUID formats that are more database friendly, it would be nice if these were supported in the
uuid
crate, since the new formats share a lot of the same internals.Describe the solution you'd like An implementation of UUIDv6, v7, and v8 from the IETF RFC.
Is it blocking? No, it would just be cool to have.
EDIT (@KodrAus): The RFC is being worked on here