Closed koslambrou closed 1 year ago
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.
We noticed this as well. I put together a patch against cardano-node
1.35.3 which memoises toBabbagePParams
. This sped up our test suite (using cooked-validators
) by 80%. This might not be the ideal fix, but it validates that there is a problem certainly for the property-testing use case.
Wouldn't it be sufficient to change the signature from:
ShelleyBasedEra era -> TxOut CtxTx era -> ProtocolParameters -> Either MinimumUTxOError Value
to: ShelleyBasedEra era -> TxOut CtxTx era -> PParams era -> Either MinimumUTxOError Value
or if we don't want to change it, provide a new function with the second signature?
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.
Internal/External Internal
Area Other
Summary
We noticed some significant performance issues with
Cardano.Api.Fees.evaluateTransactionFee
andCardano.Api.TxBody.makeTransactionBody
. After profiling the code, we noticed that the reason was because the functions would convertCardano.Api.ProtocolParameters
to cardano-ledger'sPParams
every time we call one of the functions. However, the conversion between the two datatypes take s a significant amount of time because of a plutus-core function (applyCostModelParams ) when creating the cost model.Steps to reproduce Steps to reproduce the behavior:
toLedgerPParams
such asmakeTransactionBody
andevaluateTransactionFee
.Expected behavior I'm expecting that the conversion between cardano-api's ProtocolParameter and cardano-ledger's PParams does not require significant computation.
Even better, I think we should probably not have a different datatype for protocol parameters as we already have one in cardano-ledger. Why not create a wrapper on top of it instead of defining a different data type?
System info (please complete the following information):
Screenshots and attachments
Here are some profiling results of the problematic functions:
Additional context None