[protobuf] uint32 vs int32: who is the most efficient? (Java)
I analyzed memory usage of every type of writing (in java) on
int32,sint32,uint32.
While sint32 is useful for those integers that can be both negative or
positive, int32 type is useful for data that are most likely positive.
However uint32 type cover the same range covered by integers and for
negative numbers uses a lower number of byte (only 5) than int32 (it
uses 10).
More details: with int32 type the writeInt32NoTag method in
CodedOutputStream, if the number is negative uses the sign extension
calling writeRawVarint64 method, while with uint32 the
writeUInt32NoTag method ever calls the writeRawVarint32 method that
uses at most 32 bits.
Then my question is this: why to use int32 type even though uint32
uses less bytes covering the same range?
(the same is for int64 and uint64)
I quote below the code of writeInt32NoTag and writeUInt32NoTag
methods:
public void writeUInt32NoTag(final int value) throws IOException {
writeRawVarint32(value);
}
public void writeInt32NoTag(final int value) throws IOException {
if (value = 0) {
writeRawVarint32(value);
} else {
// Must sign-extend.
writeRawVarint64(value);
}
}
*** INT32 ***
Bytes int32
1 0 = value = 127
2 128 = value = 16383
3 16384 = value = 2097151
4 2097152 = value = 268435455
5 268435455 value
10value 0
Bytessint32
1-64 = value = 63
2-8192 = value = 8191
3-1048576 = value = 1048575
4-134217728 = value = 134217727
5value -134217728 || value 134217727
Bytes uint32
1 0 = value = 127
2 128 = value = 16383
3 16384 = value = 2097151
4 2097152 = value = 268435455
5 268435455 value
5value 0
Bytes float=fixed32
4any value
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] uint32 vs int32: who is the most efficient? (Java)
Then my question is this: why to use int32 type even though uint32 uses less bytes covering the same range? The main reason would be if you ever plan on reading the message from non-Java code. What you've stated is only true in Java because it has no unsigned integral types, so protobufs have to use signed types even when a message declares a field as unsigned. In any language that has unsigned integral types, you would write -1 and the other side would read 4294967295. - Adam -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Issue 287 in protobuf: Memory leaks reported after ShutdownProtobufLibrary and program exit.
Status: New
Owner: liuj...@google.com
Labels: Type-Defect Priority-Medium
New issue 287 by jenge...@live.ca: Memory leaks reported after
ShutdownProtobufLibrary and program exit.
http://code.google.com/p/protobuf/issues/detail?id=287
What steps will reproduce the problem?
1. Create an application that includes any protobuf definition header.
2. Link statically with protobuf; you do not need to actually use any
protobuf functions/objects.
3. Set up memory leak detection with #define _CRTDBG_MAP_ALLOC and call
_CrtDumpMemoryLeaks after calling ShutdownProtobufLibrary.
What is the expected output? What do you see instead?
Several memory leak detections such as:
{139} normal block at 0x00194E68, 24 bytes long.
Data: hh 68 68 87 00 FF FF FF FF 00 00 00 00 00 00 00 00
What version of the product are you using? On what operating system?
2.4.0a on Windows 7 with Visual Studio 2010 Express Edition
Please provide any additional information below.
Not a huge deal considering I've isolated that it is in fact the library
that is creating the 'leak', but now I can't determine whether other leaks
are coming from my program or the library.
I've seen other reports of the same issue, but people mentioned that
ShutdownProtobufLibrary was implemented to handle that, but it doesn't help
in this basic program.
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Issue 287 in protobuf: Memory leaks reported after ShutdownProtobufLibrary and program exit.
Comment #1 on issue 287 by jisi@gmail.com: Memory leaks reported after ShutdownProtobufLibrary and program exit. http://code.google.com/p/protobuf/issues/detail?id=287 We use tcmalloc heap check for memory leak detection before each release. Normally there will be some leak in system library.. Do you have debug dump that shows the leaking symbol / stack traces? -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Issue 287 in protobuf: Memory leaks reported after ShutdownProtobufLibrary and program exit.
Comment #2 on issue 287 by jenge...@live.ca: Memory leaks reported after ShutdownProtobufLibrary and program exit. http://code.google.com/p/protobuf/issues/detail?id=287 I figured they weren't actual leaks in the library itself, but I'm wondering if there's a way to clean it all up before the program exits so I can properly diagnose whether the application itself has leaks. I can't get any dumps besides output in the form that I mentioned in the expected output. I can't get break points on those allocation numbers either, so I can't see which data it's actually referring to. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
