Store HumanReadableNames in-object rather than on the heap
#3733
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I've assigned @valentinewallace as a reviewer! |
Since the full encoded domain name of an HRN cannot exceed the maximum length of a DNS name (255 octets), there's not a lot of reason to store the `user` and `domain` parts of an HRN on the heap via two `String`s. Instead, here, we store one byte array with the maximum size of both labels as well as the length of the `user` and `domain` parts. Because we're now avoiding heap allocations this also implies making `HumanReadableName::new` take the `user` and `domain` parts by reference as `&str`s, rather than by value as `String`s.
TheBlueMatt
force-pushed
the
2025-04-hrn-no-heap
branch
from
7f610cb to
4583457
Compare
|
🔔 1st Reminder Hey @valentinewallace! This PR has been waiting for your review. |
|
|
||
| /// Check if the chars in `s` are allowed to be included in a hostname. | ||
| pub(crate) fn str_chars_allowed(s: &str) -> bool { | ||
| s.chars().all(|c| c.is_ascii_alphanumeric() || c == '.' || c == '_' || c == '-') |
There was a problem hiding this comment.
Can we call this method from Hostname::str_is_valid_hostname or vice versa?
| Ok(user) => user, | ||
| Err(_) => return Err(DecodeError::InvalidValue), | ||
| }; | ||
|
|
||
| let mut domain_bytes = [0; 255]; |
There was a problem hiding this comment.
Any reason to not use the 231 value mentioned above?
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since the full encoded domain name of an HRN cannot exceed the maximum length of a DNS name (255 octets), there's not a lot of reason to store the
useranddomainparts of an HRN on the heap via twoStrings.Instead, here, we store one byte array with the maximum size of both labels as well as the length of the
useranddomainparts.Because we're now avoiding heap allocations this also implies making
HumanReadableName::newtake theuseranddomainparts by reference as&strs, rather than by value asStrings.