Is there ever a good time to use int32 instead of sint32 in Google Protocol Buffers?

I’m not familiar with Google Protocol Buffers, but my interpretation of the documentation is:

• use uint32 if the value cannot be negative
• use sint32 if the value is pretty much as likely to be negative as not (for some fuzzy definition of “as likely to be”)
• use int32 if the value could be negative, but that’s much less likely than the value being positive (for example, if the application sometimes uses -1 to indicate an error or ‘unknown’ value and this is a relatively uncommon situation)

Here’s what the docs have to say about the encodings (http://code.google.com/apis/protocolbuffers/docs/encoding.html#types):

there is an important difference between the signed int types (sint32 and sint64) and the “standard” int types (int32 and int64) when it comes to encoding negative numbers. If you use int32 or int64 as the type for a negative number, the resulting varint is always ten bytes long – it is, effectively, treated like a very large unsigned integer. If you use one of the signed types, the resulting varint uses ZigZag encoding, which is much more efficient.

ZigZag encoding maps signed integers to unsigned integers so that numbers with a small absolute value (for instance, -1) have a small varint encoded value too. It does this in a way that “zig-zags” back and forth through the positive and negative integers, so that -1 is encoded as 1, 1 is encoded as 2, -2 is encoded as 3, and so on…

So it looks like even if your use of negative numbers is rare, as long as the magnitude of the numbers (including non-negative numbers) you’re passing in the protocol is on the smaller side, you might be better off using sint32. If you’re unsure, profiling would be in order.