Costing of BuiltinArray functions

[Unisay]

Closes https://github.com/IntersectMBO/plutus-private/issues/1375
Benchmark run: https://github.com/IntersectMBO/plutus/actions/runs/13907860876

(^ not zoomed out)

[Unisay]

This makes a benchmark fail if evaluation fails (wasn't the case before)

[kwxm]

Maybe you could add a comment to remind us why unsafeSplitStructuralOperational is there, since it's not immediately obvious what it's doing.

[Unisay]

@kwxm 10 and 32 here are magic numbers I chose because they were chose in similar builtin functions. This is not based on any measurements I did whatsoever.

[kwxm]

I'm not sure what we should put for the memory costs. I guess for ListToArray we'll need something with a non-zero constant term to account for some header data and then one pointer's worth of memory for each entry. @effectfully Do you remember how much room a pointer takes up?

For LengthOfArray we'll need enough memory to hold one integer, so maybe a constant cost of 1 would do, and for IndexArray it'll again be one pointer's worth.

But then again, the current numbers are pretty similar to those for other things like LengthOfByteString, so maybe these are OK. We charge 100 memory units for each CEK step anyway, so that dominates the memory cost and and extra 10 or 20 bytes for a builtin won't make a lot of difference.

[kwxm]

This looks mostly OK, although I think that the costing benchmarks need to have ArrayCostedByLength wrappers. Apart from that it looks fine.

[kwxm]

I'm not sure what we should put for the memory costs. I guess for ListToArray we'll need something with a non-zero constant term to account for some header data and then one pointer's worth of memory for each entry. @effectfully Do you remember how much room a pointer takes up?

For LengthOfArray we'll need enough memory to hold one integer, so maybe a constant cost of 1 would do, and for IndexArray it'll again be one pointer's worth.

But then again, the current numbers are pretty similar to those for other things like LengthOfByteString, so maybe these are OK. We charge 100 memory units for each CEK step anyway, so that dominates the memory cost and and extra 10 or 20 bytes for a builtin won't make a lot of difference.

[kwxm]

Maybe you could add a comment to remind us why unsafeSplitStructuralOperational is there, since it's not immediately obvious what it's doing.

[kwxm]

I think we need to use the create<N>TermBudgetingBenchWithWrappers here to wrap the array arguments, like this, although that will only really matter for listToArray since the others are constant time. We have to use the same size measures here as are used in the denotations.

Try adding the wrappers and re-running the benchmarks and see if the cost of listToArray changes significantly. If it does, you'll have to rebuild the cost model with the new results.

[kwxm]

I'm thinking that we should probably make the costed-by-length measure the default one and maybe do the same for lists (although maybe then we'll need a wrapper that measures the entire memory footprint for some of the other things involving lists). I'll make an issue to look at that separately.