On Sun, Mar 21, 2010 at 08:05, Adam Kwintkiewicz
> "... for a negative number, the resulting varint is always ten bytes long
Reason for that is the varint encoding: it only encodes the bits that
are set in an integer. For small positive values that results in a
more compact format. However, negative values always have the very
first bit set (the sign bit), so these values end up to be longer.
If you have values that are centering around zero but whose absolute
values usually don't use the full range, then the 'sint32' would be
probably a better encoding for you: it is done in 'zigzag'-encoding
that uses short encoding for small absolute values and longer for
larger absolute values.
If your numbers are big or pretty random, then you might consider fixed32.
Note however, that changing the type from int32 to sint32 or fixed32
are not compatible - so if you've already data stored that way or have
running services that talk RPC in that way, you need an upgrade path;
probably adding a new field with the new encoding, setting it in
parallel for some time (until all other users are gone). If you have
stored data the old way and don't want to recode than you've to
forever test - on reading - if the 'old' field exists and take that
> I didn't saw that part.
> 2010/3/21 Evan Jones <ev...@mit.edu>
>> On Mar 21, 2010, at 8:46 , adamdms wrote:
>>> I am wonder why int32 field (with negative value) has 10 bytes?
>>> 10 - field No 2, wire type 0
>>> FD FF FF FF FF FF FF FF FF 01 - field value = -3
>>> Can someone explain it to me?
>> See: http://code.google.com/apis/protocolbuffers/docs/encoding.html#types
>> Hope this helps,
>> Evan Jones
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at