4 Replies Latest reply on Sep 8, 2010 10:42 AM by abeall

    Serialized packet size -- determining and optimizing

    abeall Level 3

      Is it possible to determine the footprint of serialized data you are about to send across NetStream.send?

       

      I am sending frequent updates (multiple times per second) and I wish to optimize the data sent as much as possible.

       

      1) I assume that the length of property names on a serialized object affect packet size?

       

      2) Do floating point numbers with a lot of decimal places require a larger packet than a number with only a few or no decimal places?

       

      3) Does sending a bunch of null or undefined values increase packet size?

       

      4) Do certain datatypes serialize better than close counterparts, for instance Dictionary vs Object, Object vs a custom class instance, Array vs Vector, etc?

        • 1. Re: Serialized packet size -- determining and optimizing
          nimigeanu Level 2

          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

          • 2. Re: Serialized packet size -- determining and optimizing
            abeall Level 3

            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.

            • 3. Re: Serialized packet size -- determining and optimizing
              nimigeanu Level 2

              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.

              • 4. Re: Serialized packet size -- determining and optimizing
                abeall Level 3

                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.