Added a map.reserve() call for an internal hash table used to map
txid -> txPos in PreProcessedBlock::fill. This reduces the number of
allocation during block processing slightly and should shave off a few
cycles per block processed.
we weren't adding the right txidx to the history. Good thing I also
added debug code to this commit to check history.
Fixed!
Also various other nits and tweaks. Added the /debug endpoint for
sending params for debugging to the server.
This reduces the building of a set for each hashX in addBlock. Now we
flag the outputs that are safe to ignore for adding to utxo set (because
they were already spent) by flagging the OutPt directly in
PreProcessedBlock fill().
Should improve performance slightly as no more nested loops in
addBlock()
It's now an unordered_node_map, keyed off of HashX. This should be more
useful down the processing pipeline. What we had before was confusing and
difficult to use.. its only advantage was it preserved order of HashX's
in a block.
We can reproduce the order though on-demand if it turns out we need it
by adding a method to construct an array keyed off the in/out index per
hashX.
So this map approach is sufficient and likely more useful.
Turns out our custom HashX class was doing some funny things when a
HashX had a \0 byte. Likely QByteArray isn't really intended to be
inherited from. Rather than investigate what was going on -- I just
decided it's sufficient to do: using HashX = QByteArray and be done with
it.
Now our utxo set is working correctly.
We still need to figure out how to store everything.. but this is
progress.
The PreProcessedBlock is intended to be a somewhat munged/mogrified form
of a CBlock which is somewhat ready for a db insert.
This data will get passed onto the Controller thread which will set
everything up to commit the SH history, header, etc to the db.
Did some initial testing and it's pretty fast and also.. I think it's
correct (as in I'm collating the data correctly).
TODO: Some more testing.
