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

Optimize memory usage of CNode::setAddrKnown #6066

Closed

Commits on Apr 26, 2015

  1. Rolling bloom filter class

    For when you need to keep track of the last N items
    you've seen, and can tolerate some false-positives.
    gavinandresen committed Apr 26, 2015
    Configuration menu
    Copy the full SHA
    97bd572 View commit details
    Browse the repository at this point in the history
  2. Replace mruset setAddrKnown with CRollingBloomFilter addrKnown

    Use a probabilistic bloom filter to keep track of which addresses
    we think we have given our peers, instead of a list.
    
    This uses much less memory, at the cost of sometimes failing to
    relay an address to a peer-- worst case if the bloom filter happens
    to be as full as it gets, 1-in-1,000.
    
    Measured memory usage of a full mruset setAddrKnown: 650Kbytes
    Constant memory usage of CRollingBloomFilter addrKnown: 37Kbytes.
    
    This will also help heap fragmentation, because the 37K of storage
    is allocated when a CNode is created (when a connection to a peer
    is established) and then there is no per-item-remembered memory
    allocation.
    
    I plan on testing by restarting a full node with an empty peers.dat,
    running a while with -debug=addrman and -debug=net, and making sure
    that the 'addr' message traffic out is reasonable.
    (suggestions for better tests welcome)
    gavinandresen committed Apr 26, 2015
    Configuration menu
    Copy the full SHA
    eea15ff View commit details
    Browse the repository at this point in the history