Here the result when passing a list of 1000 pojos from the client to
the server:
Duration using Java Serial > Protocol Buffers Serial > Java External >
Protocol Buffers External
Average remote time = 3539624170 > 4691285205 > 3364781976 >
4805589816 nanosecs
Average serialization time = 4928 > 22203 > 2450 > 10963 nanosecs
Average de-serialization time = 2742 > 5354 > 2374 > 5790 nanosecs
Compared to passing a single pojo:
Duration using Java Serial > Protocol Buffers Serial > Java External >
Protocol Buffers External
Average remote time = 422374212 > 430878925 > 370977875 > 409553449
nanosecs
Average serialization time = 38552 > 2196927 > 35479 > 65651 nanosecs
Average de-serialization time = 4373 > 5000 > 3629 > 4785 nanosecs
The serialization using PB + Externalizable (10963) is by a factor 5
slower than using Java + Externalizable (2450)! For a single Pojo the
factor was a little less than a factor of 2 (35479 > 65651).
Tai
On Aug 18, 6:58 pm, Tai <maitai.tru...@gmail.com> wrote:
> Hi Brice,
>
> I have considered your input and uses Externalizable. My results
> compares Java vs. PB and Serialization vs. Externalization:
>
> Duration using Java Serial > Protocol Buffers Serial > Java External >
> Protocol Buffers External
> 1. Average remote time = 398658488 > 443504551 > 372961228 > 380994372
> nanosecs
> 2. Average serialization time = 29613 > 2192178 > 27937 > 57270
> nanosecs
> 3. Average de-serialization time = 3439 > 4737 > 2989 > 4456 nanosecs
>
> For 1)
> As you can see the overall remote call is faster using Externalizable
> compared to Serizalizable. But in both cases PB is slightly slower
> than Java.
> For 2)
> The serialization using Externalizable is slightly better for Java
> (29613 / 27937). For PB it is a huge difference using Externalizable
> (2192178 / 57270). But PB compared to Java is still slower.
> For 3)
> Using Externalizable for de-serialization is slightly better. But here
> again PB is slower than Java.
>
> Your suggestion to create builder once in the constructor for
> immutable objects is good. In our case it is a no-opt since they are
> not immutable.
>
> In my performance test I have two String (with key "key" and value
> "value") and one boolean member. In a production environment my key is
> max 30 and the value 50 chars long. For that I get:
>
> Duration using Java Serial > Protocol Buffers Serial > Java External >
> Protocol Buffers External
> Average remote time = 422374212 > 430878925 > 370977875 > 409553449
> nanosecs
> Average serialization time = 38552 > 2196927 > 35479 > 65651 nanosecs
> Average de-serialization time = 4373 > 5000 > 3629 > 4785 nanosecs
>
> This result brings me to the same conclusion as mentioned above. The
> next thing I will try is to have Pojo with a lot more members. Also I
> will try to pass a list of pojos from the client to the server. This
> would then cover our production environment. Looking at the
> performance in general I think the biggest boost would be in the byte
> size of a PB message. The biggest performance bottleneck is the
> network transmission and therefor the byte size should quite have a
> big impact on the performance. The other performance issues for object
> creation, serialization and deserialization is quite small compared to
> the remote call.
>
> Tai
>
> On Aug 18, 5:12 pm, Brice Figureau <brice...@daysofwonder.com> wrote:
>
> > On Tue, 2009-08-18 at 07:43 -0700, Tai wrote:
> > > What I am measuring in writeObject() and readObject() is:
>
> > > 1) For PB I only measure the writeDelimitedTo() and parseDelimitedFrom
> > > public class PojoUsingPB extends AbstractPojo implements Serializable
> > > {
> > > ...
> > > private void writeObject(java.io.ObjectOutputStream out) throws
> > > IOException {
> > > ...
> > > long start = System.nanoTime();
> > > message.writeDelimitedTo(out);
> > > long end = System.nanoTime();
> > > ...
> > > }
>
> > > private void readObject(java.io.ObjectInputStream in)
> > > throws ClassNotFoundException, IOException {
> > > long start = System.nanoTime();
> > > PojoMessage.Pojo message = PojoMessage.Pojo.parseDelimitedFrom
> > > (in);
> > > long end = System.nanoTime();
> > > ...
>
> > > 2) In Java I measure the ObjectOutputStream.writeObject() and
> > > ObjectInputStream.readObject():
> > > public class PojoUsingJava extends AbstractPojo implements
> > > Serializable {
> > > ...
> > > private void writeObject(java.io.ObjectOutputStream out) throws
> > > IOException {
> > > long start = System.nanoTime();
> > > out.writeObject(key);
> > > out.writeObject(value);
> > > out.writeBoolean(someBoolean);
> > > long end = System.nanoTime();
> > > ...
> > > }
>
> > > private void readObject(java.io.ObjectInputStream in)
> > > throws ClassNotFoundException, IOException {
> > > long start = System.nanoTime();
> > > key = (String) in.readObject();
> > > value = (String) in.readObject();
> > > someBoolean = in.readBoolean();
> > > long end = System.nanoTime();
> > > ...
>
> > > I don't know where I could have done something wrong. The results I am
> > > getting is:
> > > Duration using Java > Protocol Buffers
> > > Average remote time = 111309 > 122173 nanosecs
> > > Average serialization time = 3609 > 6586 nanosecs
> > > Average de-serialization time = 3533 > 9287 nanosecs
>
> > > Based on that PB seems to be slower and I am not coming to the same
> > > conclusion as stated in other performance tests?!
>
> > That's because you create a PB, builder and call build for each written
> > object.
> > The Java serialization doesn't have to do that, it just feeds the fields
> > of your POJO directly to the stream.
>
> > And the same applies to the deserialization.
>
> > If you were writing much more than 2 fields, then you'd see the weight
> > of creating the objects be less compared to the serialization time.
>
> > I'm not familiar with Java Serialization (anymore), but I think I
> > remember overriding writeObject and readObject still uses java
> > serialization for some parts of the current object (including
> > superclass, and so on).
> > Shouldn't you use instead an Externalizable object?
>
> > My suggestion:
> > * benchmark in situation or with larger close to production objects
> > * if your objects are immutable, create the builder in your
> > constructer, and build at that time. This way you can write multiple
> > time without incurring the creation cost.
> > * use an Externalizable object
>
> > HTH,
> > --
> > Brice Figureau
> > My Blog:http://www.masterzen.fr/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
