Cache calculated transaction IDs

After reviewing some profile data from tests, optimizing `SerializedTransaction::getTransactionID` seemed like a low-risk, moderate-reward modification. Cache the calculated transaction ID (cached results are being returned 63.57% of the time according to my test), and use references to further reduce overhead by avoiding expensive copying of `uint256` objects.

Reviews: @JoelKatz, @ximinez. 

Of particular interest is this change to use a reference instead of a copy of a `uint256` in `Key`: https://github.com/nbougalis/rippled/compare/perf?expand=1#diff-9a6914338001348adab12c49e3ab9bb9L67
Cool!

On Tue, Oct 7, 2014 at 12:29 PM, Nik Bougalis <notifications@github.com>
wrote:

> In src/ripple/app/misc/CanonicalTXSet.cpp:
>
> > @@ -73,13 +73,12 @@ bool CanonicalTXSet::Key::operator>= (Key const& rhs)const
> >
> >  void CanonicalTXSet::push_back (SerializedTransaction::ref txn)
> >  {
> > -    uint256 effectiveAccount = mSetHash;
> > -
> > -    effectiveAccount ^= to256 (txn->getSourceAccount ().getAccountID ());
> > +    auto acct = to256 (txn->getSourceAccount ().getAccountID ());
> > +    acct ^= mSetHash;
>
> Great question. It has to do with how base_uint implements ^=. By
> swapping the order around, we avoid a needless copy, small as that may seem.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/ripple/rippled/pull/610/files#r18531244>.
>



-- 
*Edward Hennis | *Senior Software Engineer | *Ripple Labs Inc.*
ed@ripple.com | www.ripple.com | *www.ripplelabs.com
<http://www.ripplelabs.com/>*
T. 352.327.8769