What is a good proxy for actual transaction / command size?

I want to measure transaction round-trip time dependent on the size of the transaction. An obvious proxy for actual transaction size would be to take the serialized byte size of the command message I’m sending, ignoring any transaction annotation overhead which I’ll consider constant. But this doesn’t seem straight-forward to do (or is it?).

Now I’m thinking since I’m only interested in the relation between size and round-trip time, and not so much in the absolute sizes, I might as well just use a payload text field on my contract, and take the size of that as a proxy. All other things kept equal, when this field gets large enough it should be the dominant factor of transaction size and it should provide me with a valid conclusion on the relation between transaction size and latency.

Do you think this is a viable approximation approach? Or are the aspects that will falsify my results that I’m not considering?

I don’t really have a full answer for you, but I would avoid using Text or strings in general because it

can represent any unicode code point

That means that the size can vary from 1 to 4 (or more?) bytes per character.

I think we have some sort of a binary type though, so that would likely be safer.

It somewhat depends on what you mean by size. Having multiple nodes in your transaction tree probably has a much bigger impact than just the size in bytes.

If you do want just the size in bytes then Text is reasonable. We use UTF16 internally (Java strings) so if you stick to ASCII you get 2 bytes per character and the caveat mentioned by @Luciano doesn’t apply.

There is no binary data type in DAML (or DAML-LF) at the moment.

1 Like

Valid point, but since I’m in control of the string I can make sure I don’t use any smileys in there :wink:

You mean if my command has complex effects like other creates and exercises? For now I’m just doing bare creates so the tree complexity should be constant.

Yeah. If you are just doing bare creates than the size probably worth measuring but usually you do more than just bare creates in your app :slight_smile:

Yes, the number of nodes in the transaction has a bigger impact than the immediate size of a single text field (unless the string is veeeeeery large).

If you’re only doing bare creates, what you basically measure is the fixed overhead of processing a transaction.