1. Yes, each character of the property name takes one byte.
2. Each "Number" is serialized as double precision float (8 bytes) regardless of decimals count or if it's actually an integer. "int" takes only half the size, 4 bytes; if your numbers are, say, no bigger than 1 million and you need a 3 decimal digit precision you may compress your floating point numbers to int by multiplying with 1000 and dividing at the other end; you may also store tiny numbers as characters
3. to my knowledge each null or undefined takes one byte to serialize
4. to test the size of any data type you may serialize it into a ByteArray and measure the length of that; for size-critical packets you can also send the actual ByteArray across the wire; it's also possible compress() and uncompress() the ByteArray but mind that this does not always make it smaller
Thanks for the answers! A follow-up question/thought:
2. What if I convert my number to a string, say 4 characters long -- that's also only 4 bytes, then? Only 2 decimal precision compared to doing math on an integer, but it would be implicitly cast on the other end correctly.
Converting to string would be a waste in any scenario i can think of. As you guessed, each decimal digit would take one byte, which is 8 bits, while it only needs roughly 3.4 bits to encode.
Converting from string to number is only seamless for a human. A parseInt() or parseFloat() takes more CPU cycles than most number operations.
What is the range and needed precision of your numbers? That is max, min and decimal digits needed. Maybe we can work out an optimal encoding.
Oops, I had bits and bytes mixed up in my head.
My number range is 0-1000, in some cases int will work fine so I'll use that, in some cases I need a little more precision.
Thanks for your help.