Fastest to convert a Java Object to byte[] and byte[] to Java Object

[Dileep Mandapam]

Hi 

   I have 2 JVMs communicated using RMI.  I wanted to know the fastest way to covert a Java Object to byte[] ,to reduce serialization overhead in Java RMI . Instead of passing java Objects to Remote server , I will pass byte[] . On the remote side ,convert byte[] to Java Object . Please suggest 

Thanks

Dileep.

        

  

[Noctarius]

Hi Dileep,

I would just try Kryo. It's a small, easy to use and fast
serialization / deserialization lib.

Chris

> --
> You received this message because you are subscribed to the Google
> Groups "java-serialization-benchmarking" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
> java-serialization-be...@googlegroups.com.
> To post to this group, send email to
> java-serializat...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/java-serialization-benchmarking.
> For more options, visit https://groups.google.com/groups/opt_out.

[Rüdiger Möller]

checkout fast-serialization, its very fast and mimics JDK serialization, no source changes required except using other stream classes. It recently made capable to run as serialization in spring webflow apps which make heavy use of widely unknown special features of JDK serialization.

[Tatu Saloranta]

Is that included in current jvm-serializers benchmark? I assume all recommendations should be, to give some basic level of credibility.

-+ Tatu +-

--

[Rüdiger Möller]

I included it and added a pull request, someone has tomerge it and update the results. (Github/RuedigerMoeller)

Regarding creditability: v1.37 runs the middleware of a large derivative exchange with +100k messages sent/received per second. On my hardware its slightly ahead kryo in total speed and produces slightly higher output. But remember this benchmark is very stringheavy and in general has only few datastructures. Kryo and FST are roundabout on par, it really depends on the structure of data being serialized. The featureset is different (fst = drop-in replacement, kry has some other intersting stuff such as basic versioning and afaik its android compatible (?) ). Just chekout yourself :-)

Am Mittwoch, 5. März 2014 19:30:07 UTC+1 schrieb cowtowncoder:

Is that included in current jvm-serializers benchmark? I assume all recommendations should be, to give some basic level of credibility.

-+ Tatu +-

On Wed, Mar 5, 2014 at 9:49 AM, Rüdiger Möller <moru...@gmail.com> wrote:

checkout fast-serialization, its very fast and mimics JDK serialization, no source changes required except using other stream classes. It recently made capable to run as serialization in spring webflow apps which make heavy use of widely unknown special features of JDK serialization.

Am Freitag, 13. September 2013 08:38:09 UTC+2 schrieb Dileep Mandapam:

Hi 

   I have 2 JVMs communicated using RMI.  I wanted to know the fastest way to covert a Java Object to byte[] ,to reduce serialization overhead in Java RMI . Instead of passing java Objects to Remote server , I will pass byte[] . On the remote side ,convert byte[] to Java Object . Please suggest 

Thanks

Dileep.

        

  

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.
To post to this group, send email to java-serialization-benchm...@googlegroups.com.

[Rüdiger Möller]

fyi: a broader test i am using to track performance. Warning: This is definitely biased, as i use this when optimizing things, so naturally fst is optimized to perform particular well on those test cases. I think in general, kryo + fst are in the same ballpark regarding performance. Regarding output size: fst offers annotations to trade output size against speed.

https://github.com/RuedigerMoeller/fast-serialization/wiki/Benchmark

Am Mittwoch, 5. März 2014 19:30:07 UTC+1 schrieb cowtowncoder:

Is that included in current jvm-serializers benchmark? I assume all recommendations should be, to give some basic level of credibility.

-+ Tatu +-

On Wed, Mar 5, 2014 at 9:49 AM, Rüdiger Möller <moru...@gmail.com> wrote:

checkout fast-serialization, its very fast and mimics JDK serialization, no source changes required except using other stream classes. It recently made capable to run as serialization in spring webflow apps which make heavy use of widely unknown special features of JDK serialization.

Am Freitag, 13. September 2013 08:38:09 UTC+2 schrieb Dileep Mandapam:

Hi 

   I have 2 JVMs communicated using RMI.  I wanted to know the fastest way to covert a Java Object to byte[] ,to reduce serialization overhead in Java RMI . Instead of passing java Objects to Remote server , I will pass byte[] . On the remote side ,convert byte[] to Java Object . Please suggest 

Thanks

Dileep.

        

  

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.
To post to this group, send email to java-serialization-benchm...@googlegroups.com.

[Tatu Saloranta]

Yes, I didn't notice pull request at first. My intent was not question validity of results, but rather there are basic results. So it's all good. And I hope we can get PR handled quickly as well.
I think we also agree on basic problem of creating fair and representative benchmark.

Other than that, what would be really interesting to me would be to run test suite on Android, and see how results vary. I know Dalvik is quite a bit more rudimentary regarding many optimizations, so results could be interesting.

-+ Tatu +-

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-be...@googlegroups.com.
To post to this group, send email to java-serializat...@googlegroups.com.

[Rüdiger Möller]

I haven't built anything for dalvik. Is it fully java compatible ? I could imagine the results strongly differ depending on the mobile cpu. I know that many multicore cpus do not use branchprediction and pipelining which will change everything :-). Additionally cache misses might be not that hard compared to CPU speed, so some optimizations will be contraproductive ..

Am Donnerstag, 6. März 2014 00:27:00 UTC+1 schrieb cowtowncoder:

Yes, I didn't notice pull request at first. My intent was not question validity of results, but rather there are basic results. So it's all good. And I hope we can get PR handled quickly as well.
I think we also agree on basic problem of creating fair and representative benchmark.

Other than that, what would be really interesting to me would be to run test suite on Android, and see how results vary. I know Dalvik is quite a bit more rudimentary regarding many optimizations, so results could be interesting.

-+ Tatu +-

On Wed, Mar 5, 2014 at 12:20 PM, Rüdiger Möller <moru...@gmail.com> wrote:

I included it and added a pull request, someone has tomerge it and update the results. (Github/RuedigerMoeller)

Regarding creditability: v1.37 runs the middleware of a large derivative exchange with +100k messages sent/received per second. On my hardware its slightly ahead kryo in total speed and produces slightly higher output. But remember this benchmark is very stringheavy and in general has only few datastructures. Kryo and FST are roundabout on par, it really depends on the structure of data being serialized. The featureset is different (fst = drop-in replacement, kry has some other intersting stuff such as basic versioning and afaik its android compatible (?) ). Just chekout yourself :-)

Am Mittwoch, 5. März 2014 19:30:07 UTC+1 schrieb cowtowncoder:

Is that included in current jvm-serializers benchmark? I assume all recommendations should be, to give some basic level of credibility.

-+ Tatu +-

On Wed, Mar 5, 2014 at 9:49 AM, Rüdiger Möller <moru...@gmail.com> wrote:

checkout fast-serialization, its very fast and mimics JDK serialization, no source changes required except using other stream classes. It recently made capable to run as serialization in spring webflow apps which make heavy use of widely unknown special features of JDK serialization.

Am Freitag, 13. September 2013 08:38:09 UTC+2 schrieb Dileep Mandapam:

Hi 

   I have 2 JVMs communicated using RMI.  I wanted to know the fastest way to covert a Java Object to byte[] ,to reduce serialization overhead in Java RMI . Instead of passing java Objects to Remote server , I will pass byte[] . On the remote side ,convert byte[] to Java Object . Please suggest 

Thanks

Dileep.

        

  

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.

To post to this group, send email to java-serialization-benchmarking...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-serialization-benchmarking.
For more options, visit https://groups.google.com/groups/opt_out.

[Kannan Goundan]

If your library generates and executes Java bytecode at runtime, it probably won't work as-is on the Android JVM.  You have to convert the Java bytecode to Dalvik bytecode before the Android JVM can load it.

Obviously the exact mobile CPU will make a difference, the exact Android release also might make an even bigger difference.  Since the Android JVM isn't as mature as the desktop/server JVM, Google is still making significant changes with every release.

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-be...@googlegroups.com.
To post to this group, send email to java-serializat...@googlegroups.com.

[Rüdiger Möller]

Only the fst-structs emulation uses byte code generation. The serialization does not make use of it, so it should run, great :-).

Yeah, you are right. Another JIT has even more impact than CPU architecture ..