RMI Performance Tests

2009-08-17 Thread Tai
Hi, I did some simple test to compare Java vs. ProtocolBuffers. I know that there is already a very verbose benchmark measuring serialization, object creation and de-serialization here: http://www.eishay.com/2009/03/more-on-benchmarking-java-serialization.html But when using RMI I am getting a t

Re: RMI Performance Tests

2009-08-17 Thread Kenton Varda
What version of protocol buffers are you using? If it's 2.0.3 or previous then you need to put this line in your proto files: option optimize_for = SPEED; In 2.1.0 and up, this is the default. On Mon, Aug 17, 2009 at 10:29 AM, Tai wrote: > > Hi, > > I did some simple test to compare Java vs.

Re: RMI Performance Tests

2009-08-17 Thread Tai
I am using 2.1.0 and as shown above the proto file uses option optimize_for = SPEED; On Aug 17, 8:56 pm, Kenton Varda wrote: > What version of protocol buffers are you using?  If it's 2.0.3 or previous > then you need to put this line in your proto files: >   option optimize_for = SPEED; > > In

Re: RMI Performance Tests

2009-08-17 Thread Kenton Varda
Oops, I missed it when skimming. > PojoMessage.Pojo message = PojoMessage.Pojo.parseFrom(in); That line won't work. Protocol buffers are not self-delimiting, so parseFrom() -- if it succeeds -- always reads the *entire* input. You should use parseDelimitedFrom() instead, and use writeDelim

Re: RMI Performance Tests

2009-08-17 Thread Tai
I have now also tried parseDelimitedFrom() and writeDelimitedTo. The performance difference is still by a factor of almost 2: Average Java time: 154333 nanosecs Average PB time: 293566 nanosecs Average Java time: 149934 nanosecs Average PB time: 275076 nanosecs I will try with a bigger message

Re: RMI Performance Tests

2009-08-17 Thread Kenton Varda
A message with three primitive fields should only take a couple hundred nanoseconds to parse or serialize, unless the strings are *huge*. I have to believe that something is wrong with the setup. On Mon, Aug 17, 2009 at 1:53 PM, Tai wrote: > > I have now also tried parseDelimitedFrom() and writ

Re: RMI Performance Tests

2009-08-18 Thread Tai
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 { ...

Re: RMI Performance Tests

2009-08-18 Thread Brice Figureau
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(jav

Re: RMI Performance Tests

2009-08-18 Thread Tai
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 > 380

Re: RMI Performance Tests

2009-08-18 Thread Tai
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 > 222

Re: RMI Performance Tests

2009-08-18 Thread Kenton Varda
For such a small message, you may find that if you use flat arrays rather than stream I/O, it may be significantly faster. That is, when serializing, call toByteArray() and then write the array to the stream, and on the parsing end, read the array first, then call parseFrom() on that. Admittedly,