This [re]moves a lock and a direct mempool.mapTx access, by copying the TX memory pool contents into a temporary vector, for use when building a new block inside CreateNewBlock().
In addition to holding CTxMemPool::cs for a shorter amount of time, this makes it easier to parallelize CreateNewBlock() -- something already done in widely circulating miner-pool patches.
The cost: memcopying the TX memory pool at each CreateNewBlock() invocation (each getwork / getmemorypool new-work request).
This [re]moves a lock and a direct mempool.mapTx access, by copying
the TX memory pool contents into a temporary vector, for use when
building a new block inside CreateNewBlock().
In addition to holding CTxMemPool::cs for a shorter amount of time,
this makes it easier to parallelize CreateNewBlock() -- something
already done in widely circulating miner-pool patches.
The cost: memcopying the TX memory pool at each CreateNewBlock()
invocation (each getwork / getmemorypool new-work request).
Neither getwork nor getmemorypool should be even trying to call CreateNewBlock in parallel... they cache its results.
(Not that there's anything wrong with this optimization.)
The former does not follow from the latter.
The cache is only accessed when you think it would be accessed: quickly upon read, or after building a block. The cache's lock need not be held while building a new block.
IMO, it's better to hold it while building a new block: instead of having 20 parallel CreateNewBlock running at potentially 1/20th the speed each for no benefit, you get a single one that finishes in 1/20th the time and the rest use the cached value from...
Closing, not enough interest. It remains a valid technique if we want to explore this avenue in the future.