Did you try what I suggested before -- serializing to a byte array instead, and then writing that to the stream all at once? It's possible that ObjectOutputStream itself is just really slow, but that when using native Java serialization it uses special, highly-optimized code paths.
On Thu, Aug 27, 2009 at 7:56 AM, Tai <maitai.tru...@gmail.com> wrote: > > Hi, > > I did some similar performance tests based on that: > http://thrift-protobuf-compare.googlecode.com/svn > > My tests runs under Java and uses Protocol Buffers 2.2.0. > > Basically I am comparing Java Serialization vs. Protocol buffers with > byte size, serialization and deserialization and my results are > similar to the performance results as stated here: > http://www.eishay.com/2009/03/more-on-benchmarking-java-serialization.html > > For serialization I use ByteArrayOutputStream (data stream in > ObjectOutputStream) and for deserialization its counterpart: > ByteArrayInputStream (data stream in ObjectInputStream). > > But doing the performance test under RMI the performance results are > totally different. Here Protocol Buffers is slower(!) than Java > Serialization. > > The only difference I can see is that it uses for serialization a > BufferedOutputStream (in ConnectionOutputStream) and a DataInputStream > (in ConnectionInputStream). > > Does anybody know why that is so? > > Tai > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
