[infinispan-dev] writeUnsignedInt() inefficient with bytes between 128 and 255

[Manik Surtani]

Your approach doesn't work because the variable length int (and long)  
approaches used write data in chunks of bytes, where data is only  
allowed in the 7 LSBs of the byte.  The MSB of each byte (which would  
otherwise contain the sign of the number in usual signed, 2's  
complement) now contains a marker indicating whether there is another  
byte to come.

On 3 Sep 2009, at 12:48, Galder Zamarreno wrote:

>
>
> On 09/03/2009 01:29 PM, Galder Zamarreno wrote:
>> On 09/03/2009 12:53 PM, Galder Zamarreno wrote:
>>> Hi,
>>>
>>> While looking at https://jira.jboss.org/jira/browse/ISPN-149, I've
>>> realised that writeUnsignedInt(), due to its dynamic behaivour, it's
>>> more efficient than using a leading byte and then writing a byte,  
>>> short
>>> or int.
>>>
>>> However, I've spotted an unefficiency in
>>> UnsignedNumeric.writeUnsignedInt() which is that if you write a byte
>>> that's between 128-255, it writes two bytes, whereas in theory, you
>>> could just write it as a single unsigned byte.
>>>
>>> Now, I'm not an expert on these methods, but I believe a
>>> writeUnsignedInt like this would make 128-255 bytes be written as  
>>> 1 byte
>>> too:
>>>
>>>      public static void writeUnsignedInt(ObjectOutput out, int i)  
>>> throws
>>> IOException {
>>>         while ((i&   ~0xFF) != 0) {
>>>            out.writeByte((byte) ((i&   0xFF) | 0x100));
>>>            i>>>= 8;
>>>         }
>>>         out.writeByte((byte) i);
>>>      }
>>>
>>> And the read part would look like:
>>>
>>>      public static int readUnsignedInt(ObjectInput in) throws  
>>> IOException {
>>>         int b = in.readUnsignedByte();
>>>         int i = b&   0xFF;
>>>         for (int shift = 8; (b&   0x100) != 0; shift += 8) {
>>>            b = in.readUnsignedByte();
>>>            i |= (b&   0xFFL)<<   shift;
>>>         }
>>>         return i;
>>>      }
>>
>> Hmmm, the read part is not working as expected. Trying to figure  
>> out how
>> to get on values equal or bigger than 256 to read the next byte.
>
> Hmmm, this is trickier than I thought. In the current solution, you  
> know
> you have to read more bytes cos the byte you've just read is negative.
> However, if you use the full 4 bytes, how do you know that you need to
> read another byte? Hmmmm....
>
>>
>>> Manik, I think you created these methods in the 1st place, thoughts?
>>> CC'ing David M L who's quite an expert on this too.
>>>
>>> Cheers,
>>
>
> -- 
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org