The best way to think of it is:

Builder : Java Message :: C++ Message : const C++ Message

As far as performance goes, it is a common mistake to confuse C/C++
heap memory allocation costs to Java heap allocation. In the common
case, allocations in Java are just a few instructions... comperable to
stack allocations in C/C++. What normally gets you in Java is the
initialization cost, and in this particlar scenario there is no way
around that.

If you are worried, you could benchmark the difference between
constantly allocating builders as you go vs. starting with an array of
N builders (allocating the array would be done outside of the
benchmark). I am sure it will prove enlightening.


On 7/24/09, Kenton Varda <ken...@google.com> wrote:
> On Thu, Jul 23, 2009 at 7:15 PM, alopecoid <alopec...@gmail.com> wrote:
>
>> Hmm... that strikes me as strange. I understand that the Message
>> objects are immutable, but the Builders are as well? I thought that
>> they would work more along the lines of String and StringBuilder,
>> where String is obviously immutable and StringBuilder is mutable/
>> reusable.
>
>
> The point is that it's the Message object that contains all the stuff
> allocated by the Builder, and therefore none of that stuff can actually be
> reused.  (When you call build(), nothing is copied -- it just returns the
> object that it has been working on.)  So reusing the builder itself is kind
> of useless, because it's just a trivial object containing one pointer (to
> the message object it is working on constructing).
>
>
>> But while we're on the subject, I have been looking for some rough
>> benchmarks comparing the performance of Protocol Buffers in Java
>> versus C++. Do you (the collective you) have any [rough] idea as to
>> how they compare performance wise? I am thinking more in terms of
>> batch-style processing (disk I/O, parsing centric) rather than RPC
>> centric usage patterns. Any experiences you can share would be great.
>
>
> I have some benchmarks that IIRC show that Java parsing and serialization is
> roughly half the speed of C++.  As I recall a lot of the speed difference is
> from UTF-8 decoding/encoding -- in C++ we just leave the bytes encoded, but
> in Java we need to decode them in order to construct standard String
> objects.
>
> I've been planning to release these benchmarks publicly but it will take
> some work and there's a lot of higher-priority stuff to do.  :/  (I think
> Jon Skeet did get the Java side of the benchmarks into SVN but there's no
> C++ equivalent yet.)
>
> >
>

-- 
Sent from my mobile device

Chris

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to