-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Tuid
#8999
Improve Tuid
#8999
Conversation
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
bb32ec0
to
f806716
Compare
f806716
to
83ee7c6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it, except for the string representation shenanigans.
fn test_tuid_size_and_alignment() { | ||
assert_eq!(std::mem::size_of::<Tuid>(), 16); | ||
assert_eq!(std::mem::align_of::<Tuid>(), 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use static_assertions
for these things these days?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can, but it adds a dependency for no gain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes the type self-documenting in ways that comments or freestanding tests never will, and static_assertions
is already an indirect dep of re_tuid
.
/// The format uses upper case for the first 16 hex digits, and lower case for the last 16 hex digits. | ||
/// This is to make it easily distinguished from other hex strings. | ||
/// | ||
/// Example: `182342300C5F8C327a7b4a6e5a379ac4` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eeeeeeeh, this part I'm really not a fan tbh, but okay 🤷
Co-authored-by: Clement Rey <[email protected]>
### Related * Part of #8992 ### What Improve `re_tuid::Tuid`, and by extension `RowId` and `ChunkId` (which are just typesafe wrappers around `Tuid`) ### Details * Implement `from_str` for `Tuid/RowId/ChunkId` * Slightly modify how Tuid is formatted as a string (in backwards/forwards compatible way!)] * Implement bytemucking * Align to bytes (see below) ### Change `Tuid` alignment from `8` to `1` This will allow us to cast raw bytes into a `&[RowId]`. `arrow-rs` already aligns all allocations to 64 bytes, so _theoretically_ there would be nothing to stop us from already doing this, but this is the "better safe than sorry" approach. `uuid:::Uuuid` is also aligned to bytes, FWIW. * `Tuid::new` becomes ~7% slower * `Tuid::cmp` is unaffected --------- Co-authored-by: Clement Rey <[email protected]>
### Related * Part of #8992 ### What Improve `re_tuid::Tuid`, and by extension `RowId` and `ChunkId` (which are just typesafe wrappers around `Tuid`) ### Details * Implement `from_str` for `Tuid/RowId/ChunkId` * Slightly modify how Tuid is formatted as a string (in backwards/forwards compatible way!)] * Implement bytemucking * Align to bytes (see below) ### Change `Tuid` alignment from `8` to `1` This will allow us to cast raw bytes into a `&[RowId]`. `arrow-rs` already aligns all allocations to 64 bytes, so _theoretically_ there would be nothing to stop us from already doing this, but this is the "better safe than sorry" approach. `uuid:::Uuuid` is also aligned to bytes, FWIW. * `Tuid::new` becomes ~7% slower * `Tuid::cmp` is unaffected --------- Co-authored-by: Clement Rey <[email protected]>
Related
What
Improve
re_tuid::Tuid
, and by extensionRowId
andChunkId
(which are just typesafe wrappers aroundTuid
)Details
from_str
forTuid/RowId/ChunkId
Change
Tuid
alignment from8
to1
This will allow us to cast raw bytes into a
&[RowId]
.arrow-rs
already aligns all allocations to 64 bytes, so theoretically there would be nothing to stop us from already doing this, but this is the "better safe than sorry" approach.uuid:::Uuuid
is also aligned to bytes, FWIW.Tuid::new
becomes ~7% slowerTuid::cmp
is unaffected