Permalink
Browse files

comments

  • Loading branch information...
jedmccaleb committed May 10, 2014
1 parent 5f637c2 commit 36f92c02289f7792e2b92b56a526b7b96f2b545e
Showing with 20 additions and 3 deletions.
  1. +18 −1 src/ripple_app/shamap/SHAMap.h
  2. +2 −2 src/ripple_app/shamap/SHAMapTreeNode.h
@@ -23,6 +23,23 @@
#include "../ripple/radmap/ripple_radmap.h"
#include "../main/FullBelowCache.h"
/*
Used for:
the Ledger
the set of transaction in a ledger
Figuring the delta between two transaction sets
Looks like:
We have a hash table of all Ledger entries mTNbyID
We have a tree of entries: root
The tree just has id's which we then have to look up in mTNbyID?
there is some cache that we check when we are looking up items?
What is the point of the tree?
*/
enum SHAMapState
{
smsModifying = 0, // Objects can be added and removed (like an open ledger)
@@ -323,7 +340,7 @@ class SHAMap
FullBelowCache& m_fullBelowCache;
uint32 mSeq;
uint32 mLedgerSeq; // sequence number of ledger this is part of
SyncUnorderedMapType< SHAMapNode, SHAMapTreeNode::pointer > mTNByID;
SyncUnorderedMapType< SHAMapNode, SHAMapTreeNode::pointer > mTNByID; // Tree Node by ID. hash table of all the nodes
boost::shared_ptr<NodeMap> mDirtyNodes;
SHAMapTreeNode::pointer root;
SHAMapState mState;
@@ -175,11 +175,11 @@ class SHAMapTreeNode
friend class SHAMap;
uint256 mHash;
uint256 mHashes[16];
uint256 mHashes[16]; // hashes of the nodes under this one
SHAMapItem::pointer mItem;
uint32 mSeq, mAccessSeq;
TNType mType;
int mIsBranch;
int mIsBranch; // JED: why is this an int and not a bool? I think it is a bitfield that says if the branch at bit i is there or not

This comment has been minimized.

Show comment
Hide comment
@JoelKatz

JoelKatz Aug 2, 2014

Contributor

It's a bitfield indicating which branches are non-empty.

@JoelKatz

JoelKatz Aug 2, 2014

Contributor

It's a bitfield indicating which branches are non-empty.

This comment has been minimized.

Show comment
Hide comment
@tmagik

tmagik Jan 7, 2015

Why is a bitfield specified as a bare int with no size qualifier? This seems like it would cause much pain as the default int size changes from 32->64->128 bit ints

@tmagik

tmagik Jan 7, 2015

Why is a bitfield specified as a bare int with no size qualifier? This seems like it would cause much pain as the default int size changes from 32->64->128 bit ints

This comment has been minimized.

Show comment
Hide comment
@JoelKatz

JoelKatz Jan 7, 2015

Contributor

Making an int larger won't cause any pain. It will just result in more zero bits. Since there's only one of these in the structure, it's hard to see any benefit to making it smaller than native size.

@JoelKatz

JoelKatz Jan 7, 2015

Contributor

Making an int larger won't cause any pain. It will just result in more zero bits. Since there's only one of these in the structure, it's hard to see any benefit to making it smaller than native size.

This comment has been minimized.

Show comment
Hide comment
@tmagik

tmagik Jan 11, 2015

I guess it depends on how big these structures get, and if a 32 or 64 bit int throws off alignment of the whole structure when only 16 are needed. Which has me wondering what a 256-radix tree would do, or even if it would make sense.

@tmagik

tmagik Jan 11, 2015

I guess it depends on how big these structures get, and if a 32 or 64 bit int throws off alignment of the whole structure when only 16 are needed. Which has me wondering what a 256-radix tree would do, or even if it would make sense.

bool mFullBelow;
bool updateHash ();

0 comments on commit 36f92c0

Please sign in to comment.