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

Replace Strings with FastStr #211

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

AbstractiveNord
Copy link

Replaced Strings type with FastStr, removed a lot of to_owned(), some autoformatting.

Pull request checklist:

  • CHANGELOG.md was updated, if applicable

@RAnders00
Copy link
Collaborator

RAnders00 commented Mar 18, 2024

I'm not convinced this is better, since it adds a dependency (code size, compile times) and there's no benchmark to compare before and after. The fast-str crate also says "What Is It For?
FastStr is better than String as long as it is not often necessary to modify strings and connect strings.", which is something that's done extensively in the parsing code. Unless we can get a benchmark in and it shows to create a huge plus in performance, I'm putting a big question mark on this change.

Not to mention that is this a severely breaking change and will cause headache on the crate's users.

@AbstractiveNord
Copy link
Author

It's okay, I can benchmark this approach later on. I didn't get about breaking change, because public API is same. Can you suggest some scenarios to bench?

@@ -248,7 +249,7 @@ impl<T: Transport, L: LoginCredentials> ClientLoopWorker<T, L> {
///
/// The client will make best attempts to stay joined to this channel. I/O errors will be
/// compensated by retrying the join process. For this reason, this method returns no error.
fn join(&mut self, channel_login: String) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these kinds of changes, where the type in a struct or the argument type of a function changes, are breaking changes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, looks to be missed. I've planned to rewrite it into impl Into<FastStr>, to save backwards compatibility.

@RAnders00
Copy link
Collaborator

It's okay, I can benchmark this approach later on. I didn't get about breaking change, because public API is same. Can you suggest some scenarios to bench?

I've just not gotten around to it, but a large sample (maybe 10k-100k) actual messages logged from various twitch channels should give a realistic real-use scenario, run through the message parser (parsing to ServerMessage). I estimate the message parsing is the most CPU-intensive part of the library.

@AbstractiveNord
Copy link
Author

It's okay, I can benchmark this approach later on. I didn't get about breaking change, because public API is same. Can you suggest some scenarios to bench?

I've just not gotten around to it, but a large sample (maybe 10k-100k) actual messages logged from various twitch channels should give a realistic real-use scenario, run through the message parser (parsing to ServerMessage). I estimate the message parsing is the most CPU-intensive part of the library.

I am not sure, did I patch parser at all. I confirm that's a lot of to_owned() have been removed. I'll inform about bench results.

pub struct IRCMessage {
/// A map of additional key-value tags on this message.
pub tags: IRCTags,
/// The "prefix" of this message, as defined by RFC 2812. Typically specifies the sending
/// server and/or user.
pub prefix: Option<IRCPrefix>,
/// A command like `PRIVMSG` or `001` (see RFC 2812 for the definition).
pub command: String,
pub command: FastStr,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course you did, for example here and approx. 80% of the files changed are the message data types.

@RAnders00
Copy link
Collaborator

Thank you for looking into making a benchmark!

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

Successfully merging this pull request may close these issues.

2 participants