You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Especially when parsing IRC messages, a lot of Strings are created that are really just substrings of the original message, so a &str would be more efficient. This would make the message struct tied to a lifetime (of the backing String) making it hard to move the struct around. However, there are crates out there that would make this simpler, like yoke.
I think you're right, that would make a lot of sense. I hadn't heard of yoke, actually. When I last looked into it, self-referential structs were a royal pain in the ass.
It may be possible to partially get around this by using inline strings. Something like [SmartString] or [compact_str] may work. It wont be a lot (24 bytes at most) but it's better than nothing.
[SmartString]: https://lib.rs/crates/smartstring
[compact_str]: https://lib.rs/crates/compact_str
Especially when parsing IRC messages, a lot of
String
s are created that are really just substrings of the original message, so a&str
would be more efficient. This would make the message struct tied to a lifetime (of the backingString
) making it hard to move the struct around. However, there are crates out there that would make this simpler, likeyoke
.I think it's worth at least discussing this.
Also see this article on
yoke
: Not a Yoking Matter (Zero-Copy #1).The text was updated successfully, but these errors were encountered: