[FEAT] - Mempool could do operations at the "ledgerstate" level to prevent projection and injection

[jasagredo]

The mempool makes some operations on ledger tables when adding transactions, take for example this left-heavy flamegraph from a db-analyser run on a full-blocks synthetic chain:

Roughly 60% of the time of applying the transactions is spent in prepending the differences and in applying the diffs to the tables. And of that the 100% of it is spent in projecting and injecting the tables.

The reason behind this is that prependDiffs for example is defined in terms of ledger tables:

rawPrependDiffs ::
     Ord k
  => DiffMK k v -- ^ Earlier differences
  -> DiffMK k v -- ^ Later differences
  -> DiffMK k v
rawPrependDiffs (DiffMK d1) (DiffMK d2) = DiffMK (d1 <> d2)

-- | Prepend diffs from the first ledger state to the diffs from the second
-- ledger state. Returns ledger tables.
prependDiffs' ::
     (SameUtxoTypes l l'', SameUtxoTypes l' l'', HasLedgerTables l, HasLedgerTables l', HasLedgerTables l'')
  => l DiffMK -> l' DiffMK -> LedgerTables l'' DiffMK
prependDiffs' l1 l2 = ltliftA2 rawPrependDiffs (ltprj l1) (ltprj l2)

-- | Prepend the diffs from @l1@ to @l2@. Returns @l2@.
prependDiffs ::
     (SameUtxoTypes l l', HasLedgerTables l, HasLedgerTables l')
  => l DiffMK -> l' DiffMK -> l' DiffMK
prependDiffs l1 l2 = ltwith l2 $ prependDiffs' l1 l2

We use ltprj and ltwith with go from ledger states to tables. This imposes in the HFC case a conversion between CardanoTxOut and ShelleyTxOut, which is a newtype-like conversion as tables are always in the latest era.

To mitigate this, we could lift these two operations to work in ledgerstates so that we don't extract the tables ever.

In any case the scale of time of this optimization should be negligible in the grand picture.