-
Notifications
You must be signed in to change notification settings - Fork 75
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
Fix various performance issues #724
base: main
Are you sure you want to change the base?
Conversation
pub struct Server(String); | ||
#[serde(transparent)] | ||
pub struct Server { | ||
name: Arc<str>, |
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 would prefer to change this to a named struct instead of a tuple struct, since future PRs will add fields here.
This commit includes various fixes that I have found working on bouncer-networks. It includes several performance benefits—such as changing `Server` to be an `Arc<str>` which removes much of the copying overhead. I have also made sure that there is only one copy of the server config in the `Halloy` struct, which was previously duplicated for seemingly no reason. Still, several performance issues go un-addressed. such as the duplication of server configs between threads (should this also be an `Arc<config>`?) and the copying of `client` structs. I have also made some changes to the client. The capability negotiation process has been streamlined, and I've eliminated some branching with preference toward pattern matching. I've also fixed a slight error with halloy, making sure that it detects the end of registration correctly (matching other clients). I have also made changes to the `Cargo.toml` in the `data` crate. This is to fix some compilation issues when building that crate in isolation. I would like this fixed so that it'd be easier to run `data` crate tests in isolation. Ideally I think that each of the sub-crates should be tested individually in CI—but that's out of scope for this PR. In my opinion, this resolves squidowl#640
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.
} | ||
if newly_contains("extended-monitor") { | ||
requested.push("extended-monitor"); | ||
} | ||
if contains("account-notify") || newly_contains("account-notify") { | ||
if newly_contains("account-notify") { |
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 think we can skip this and condense the conditionals, similar to what you did above. Everything else looks good to me.
This commit includes various fixes that I have found working on bouncer-networks. It includes several performance benefits—such as changing
Server
to be anArc<str>
which removes much of the copying overhead. I have also made sure that there is only one copy of the server config in theHalloy
struct, which was previously duplicated for seemingly no reason.Still, several performance issues go un-addressed. such as the duplication of server configs between threads (should this also be an
Arc<config>
?) and the copying ofclient
structs.I have also made some changes to the client. The capability negotiation process has been streamlined, and I've eliminated some branching with preference toward pattern matching. I've also fixed a slight error with halloy, making sure that it detects the end of registration correctly (matching other clients).
I have also made changes to the
Cargo.toml
in thedata
crate. This is to fix some compilation issues when building that crate in isolation. I would like this fixed so that it'd be easier to rundata
crate tests in isolation.Ideally I think that each of the sub-crates should be tested individually in CI—but that's out of scope for this PR.
In my opinion, this resolves #640