Round one of fixes to avoid ridiculous numbers of spurious copy constructor and destructor calls.

Most of these fixes involve calls to BOOST_FOREACH to iterate over a map or unordered_map where the
iterator type didn't perfectly match the internal type, so a reference into the map couldn't be created
and a new value/content pair had to be created for each iteration.
This commit is contained in:
JoelKatz
2012-12-17 20:20:24 -08:00
parent 961ac4690e
commit 2a06686b7c
14 changed files with 29 additions and 27 deletions

View File

@@ -140,7 +140,7 @@ bool ConnectionPool::peerAvailable(std::string& strIp, int& iPort)
vstrIpPort.reserve(mIpMap.size());
BOOST_FOREACH(pipPeer ipPeer, mIpMap)
BOOST_FOREACH(const vtPeer& ipPeer, mIpMap)
{
const std::string& strIp = ipPeer.first.first;
int iPort = ipPeer.first.second;
@@ -251,7 +251,7 @@ int ConnectionPool::relayMessage(Peer* fromPeer, const PackedMessage::pointer& m
int sentTo = 0;
boost::mutex::scoped_lock sl(mPeerLock);
BOOST_FOREACH(naPeer pair, mConnectedMap)
BOOST_FOREACH(const vtConMap& pair, mConnectedMap)
{
Peer::ref peer = pair.second;
if (!peer)
@@ -270,7 +270,7 @@ void ConnectionPool::relayMessageBut(const std::set<uint64>& fromPeers, const Pa
{ // Relay message to all but the specified peers
boost::mutex::scoped_lock sl(mPeerLock);
BOOST_FOREACH(naPeer pair, mConnectedMap)
BOOST_FOREACH(const vtConMap& pair, mConnectedMap)
{
Peer::ref peer = pair.second;
if (peer->isConnected() && (fromPeers.count(peer->getPeerId()) == 0))
@@ -388,7 +388,7 @@ std::vector<Peer::pointer> ConnectionPool::getPeerVector()
ret.reserve(mConnectedMap.size());
BOOST_FOREACH(naPeer pair, mConnectedMap)
BOOST_FOREACH(const vtConMap& pair, mConnectedMap)
{
assert(!!pair.second);
ret.push_back(pair.second);