Maybe it would be a good idea to tag plugin custom_jsons which need to be parsed by hived or hive core middleware differently from third party custom_jsons which don't (with potentially lower RC cost for the latter)?
You are viewing a single comment's thread from:
They are tagged differently. In current version only
delegate_rc_operation(withrctag) carries extra cost. All other custom_jsons are only charged base cost, no matter if they are those used by essential services like Hivemind or third party. (By "current" I mean HF26 version :o) )I think we're talking past each other here. Currently all custom_jsons have to be parsed because they might be used by a hived or hivemind. What I'm suggesting is that custom_json be broken out into one kind that is parsed by core services, and another that can be used by third parties but is not parsed by hived or hivemind. The latter would presumably have lower CPU usage (almost none beyond the base to parse an op at all) and therefore could have lower RC cost.
I mean the latter doesn't even have to be json at all. It could be custom_text. We do have custom_binary (I guess this has lower cost, or it should), but people seem to prefer storing json/text rather than packing a binary.
No, hived only checks if
jsonfield of custom_json is a valid UTF-8 JSON string. It does not build variant object out of that string in order to access its fields. To see if it might need to actually do that, it usesidfield that is right there in the operation itself.Moreover the execution time associated with it being custom_json is trivial in comparison with cost associated with the transaction. Validation, execution and RC handling of custom_json (yes, cost of calculating RC is also included in the cost of operations) all together take 1509 ns on average. On the other hand duplicate check, tapos check and charging for RC takes 6622 ns plus a whooping 94165 ns per signature. Transaction itself also costs some state (128 byte-hours) and history bytes (size of transaction). As you can see, even if we started to charge zero for execution of
custom_json_operation, the difference wouldn't matter.If you are thinking about looking for a way to speed up calculation of public keys from signatures (most obvious target when it comes to execution time), it would help all transactions and would be very welcome, however most of the cost of transactions with custom_jsons comes from history bytes, not execution time.
The timings are obviously constants - they don't depend on the hardware the node is run on, because otherwise nodes would constantly disagree on RC mana of users. They were collected by @gtg on average computer recommended for witnesses - see issue #205. They are likely to be updated (lowered) with future hardforks as more powerful hardware is required to run witness node.
Thank you. Pointing out that any processing of the content isn't significant is a good reason further optimization doesn't appear to be needed. Good explanation.