misc improvements to json_serialize_to_buffer() performance

[commodo]

Well, the bottleneck for the our use-case is sprintf() for numbers. There are too many numbers to convert on an embedded system.

One minor improvement that I am still hesitant to push, is to return a pessimistic buf-size when json_serialization_size() gets called i.e. to return PARSON_NUM_BUF_SIZE instead of calling spritnf() (which would be a good performance booster). This changes some semantics (also in tests), where more memory would get allocated (thantneeded), but that wouldn't be too bad considering that sprintf() is too slow (which opens up a discussion about which is worse: speed or memory over-use).

sprintf() performance is presented here: https://aras-p.info/blog/2022/02/25/Curious-lack-of-sprintf-scaling/

So in this (patch) series, the idea (I am presenting) is that a user can/could provide their own serializer function for double/numbers (in case they don't like sprintf()). But I also included some minor perf stuff that I found along the way. The improvement (the other stuff adds) isl small, but (generally) they're still worth considering.

Signed-off-by: Alexandru Ardelean [email protected]

[kgabis]

This looks quite good but I'll need a few days to have a deeper look.

[commodo]

sure: no hurry from my side;

we need this into the azure-iot-sdk stuff, so these changes will pop-up after some months into our tree (after they trickle);

we're still discussing about how to handle the sprintf() bottle neck; it may just end up needing to not do JSON-to-string conversions every now-n-then;

[commodo]

updated based on comment;

[kgabis]

I've tidied up your changes a bit and restored functions calls to json_value_get_*. I know it feels redundant but I'd rather if it's consistent with the rest of the codebase.

[commodo]

I've tidied up your changes a bit and restored functions calls to json_value_get_*. I know it feels redundant but I'd rather if it's consistent with the rest of the codebase.

ack no worries from me;

the compiler should be able to optimize there (i hope) to better inline those bits; the biggest performance hit we get is from sprintf() anyway, because there are too many numbers in some json-s