Skip to content
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

Reduce Allocations #178

Open
Nerixyz opened this issue Sep 1, 2022 · 3 comments
Open

Reduce Allocations #178

Nerixyz opened this issue Sep 1, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@Nerixyz
Copy link
Contributor

Nerixyz commented Sep 1, 2022

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 it's worth at least discussing this.

Also see this article on yoke: Not a Yoking Matter (Zero-Copy #1).

@RAnders00 RAnders00 added the enhancement New feature or request label Sep 5, 2022
@RAnders00
Copy link
Collaborator

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.

@MisterEggnog
Copy link

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

@RAnders00
Copy link
Collaborator

Mentioning fast-str here as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants