Is it worth lowering the cost of `equalsData` in the `False` case?

[effectfully]

#7138 lowers down the cost of equalsData when the two Data objects aren't equal. It would be great to have lower cost for equalsData, but implementing it properly is quite challenging, so we should first check if the impact is worth the trouble.

This issue is for replaying all the on-chain evaluation events using the #7138 branch recording the budget and success results. We're interested in:

• what percentage (+ an absolute number) of total script executions gets 0-1% cheaper
• 2-5%
• 5-10%
• 10-15%
• ...
• 95-100%
• whether any of the script executions gets more expensive (that would be a bug)

[Unisay]

Meeting notes

[SeungheonOh]

I've been running real world scripts today with both current Cek machine and one with updated costing on equalsData. So far, 11,939,962 scripts is been re-run with both Cek machines. Of 11 billion evaluations, around 200,000 evaluations are effected; this is ~2% of the all evaluations.

Below is the distribution of percent changes of these 200,000 evaluations:

So, it's mostly 0~1% improvement. 2.86% is the maximum. Also, this only CPU budget; memory budget did not change at all. Note, these points are evaluation, not unique validators; some validators were evaluated multiple times with different script contexts.

The result makes sense. If equalsData is used to check equality of data-encoded datatype, like comparing equality of TxOutRef, the assumption is that the structure of them are identical, so it needs to go over all values making no changes to the cost. The only use case where new costing would benefit is where validator is comparing two different arbitrary data where at least one has an unknown structure. In real world validator, source of this datum of unknown structure would be Datum and Redeemer, but most validator would compare Datum or Redeemer to be equal with some set value and fail if they are not equal. This means, the only scripts that benefits from this costing changes are the ones that expects its Datum or Redeemer to be not equal to some set value, which is pretty rare as shown.