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.

Sign up for GitHub

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

v2.0: removes early return if prune_messages are empty (backport of #3006) #3011

Merged
merged 1 commit into from
Sep 30, 2024
Merged

v2.0: removes early return if prune_messages are empty (backport of #3006) #3011

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 3 additions & 4 deletions gossip/src/cluster_info.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2412,9 +2412,6 @@ impl ClusterInfo {
.collect()
})
};
if prune_messages.is_empty() {
return;
}
let mut packet_batch = PacketBatch::new_unpinned_with_recycler_data_and_dests(
recycler,
"handle_batch_push_messages",
Expand Down Expand Up @@ -2444,7 +2441,9 @@ impl ClusterInfo {
self.stats
.packets_sent_push_messages_count
.add_relaxed((packet_batch.len() - num_prune_packets) as u64);
let _ = response_sender.send(packet_batch);
if !packet_batch.is_empty() {
Copy link

Choose a reason for hiding this comment

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

Should all the stats counter increases be surrounded by this if as well?

Copy link

Choose a reason for hiding this comment

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

hmmm, not sure it matters much either way:

  • the stats counters are just doing an atomic add, and even if the argument is zero it wouldn't really have a measurable impact.
  • except for the prune counters, I would expect the other counters to be almost always non-zero anyways. i.e. we always push some messages out when receiving push messages.

Given that, I lean towards keeping the if branch shorter and simpler here. But if we decide to change that, because this is a backport, I would rather to do so on master branch first otherwise v2.0 becomes inconsistent with master.

Copy link

Choose a reason for hiding this comment

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

assuming the question was asked wrt the metrics remaining accurate with this change?

Copy link

Choose a reason for hiding this comment

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

The metrics are accurate.
My understanding was that the comment was about avoiding metric.add_relaxed(0) which is a no-op.

Copy link

Choose a reason for hiding this comment

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

Yep, trying to avoid some wasted time on no-ops and make it match ping handling a little more closely https://github.com/anza-xyz/agave/blob/master/gossip/src/cluster_info.rs#L2561-L2571

But I don't see anything functionally wrong, and agree this isn't turning the needle on performance in any meaningful way.

let _ = response_sender.send(packet_batch);
}
}

fn require_stake_for_gossip(&self, stakes: &HashMap<Pubkey, u64>) -> bool {
Expand Down