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

Use boost::circular_buffer: #3400

Closed
wants to merge 1 commit into from
Closed

Use boost::circular_buffer: #3400

Show file tree
Hide file tree
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
8 changes: 0 additions & 8 deletions src/ripple/overlay/impl/PeerImp.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1961,9 +1961,6 @@ PeerImp::onMessage(std::shared_ptr<protocol::TMHaveTransactionSet> const& m)
return;
}

if (recentTxSets_.size() == 128)
recentTxSets_.pop_front();

recentTxSets_.push_back(hash);
}
}
Expand Down Expand Up @@ -2324,11 +2321,6 @@ PeerImp::addLedger(
recentLedgers_.end())
return;

// VFALCO TODO See if a sorted vector would be better.
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering why this comment is here. It seems that circular_buffer is the obvious choice here, so I'm wondering why Vinny was suggesting a sorted vector.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We use std::find in a few places, so a sorted vector would make it possible to use std::binary_search instead of std::find.

It would trade additional insertion complexity for fewer comparisons during a search. I don't know how this comes down.

Copy link
Contributor

Choose a reason for hiding this comment

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

I've done a few studies on this and it depends on the length of the sequence, complexity of the comparison operator and size of each element. But the takeaway is that if sizeof and comparison are fairly cheap, the linear search wins for a surprising length. I don't have the exact numbers off the top of my head, but I believe it was in the hundreds, not in the tens, before binary search began to win.


if (recentLedgers_.size() == 128)
recentLedgers_.pop_front();

recentLedgers_.push_back(hash);
}

Expand Down
16 changes: 3 additions & 13 deletions src/ripple/overlay/impl/PeerImp.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,6 @@
#include <boost/endian/conversion.hpp>
#include <boost/optional.hpp>
#include <cstdint>
#include <deque>
#include <queue>
#include <shared_mutex>

Expand Down Expand Up @@ -134,8 +133,9 @@ class PeerImp : public Peer,
LedgerIndex maxLedger_ = 0;
uint256 closedLedgerHash_;
uint256 previousLedgerHash_;
std::deque<uint256> recentLedgers_;
std::deque<uint256> recentTxSets_;

boost::circular_buffer<uint256> recentLedgers_{128};
boost::circular_buffer<uint256> recentTxSets_{128};

boost::optional<std::chrono::milliseconds> latency_;
boost::optional<std::uint32_t> lastPingSeq_;
Expand Down Expand Up @@ -495,13 +495,6 @@ class PeerImp : public Peer,
//
//--------------------------------------------------------------------------

static error_code
invalid_argument_error()
{
return boost::system::errc::make_error_code(
boost::system::errc::invalid_argument);
}

void
onMessageUnknown(std::uint16_t type);

Expand Down Expand Up @@ -565,9 +558,6 @@ class PeerImp : public Peer,
}

//--------------------------------------------------------------------------
void
setLedgerState();

// lockedRecentLock is passed as a reminder to callers that recentLock_
// must be locked.
void
Expand Down