You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since ObjectInputStream and ObjectOutputStream are both part of the JDK, I consider them like the default implementation we can use to perform Object (de)serialization.
I would therefore expect in the README.md some rationale on why Kryo is better than that implementation, and how does it compare in regards to performance.
Thanks!
The text was updated successfully, but these errors were encountered:
In my experience, Kryo is 3-5x faster than JDK serialization when using the default FieldSerializer.
Performance gains are lower for the compatible serializers, but they offer more flexibility to evolve your data structures compared to JDK serialization.
A relatively straight forward option would be to add another benchmark to FieldSerializerBenchmark that uses default JDK serialization and re-generate the graphs.
This would be a good first issue for someone looking to contribute to Kryo.
Thanks for the answer, this is already helping me.
Since I'm in the process of reducing the amount of dependencies we have (and that's why I was looking into Kryo) I'm not really looking to contribute to Kryo for now. But I like the "here's how you could contribute" approach, This Is The Way™.
Since
ObjectInputStream
andObjectOutputStream
are both part of the JDK, I consider them like the default implementation we can use to perform Object (de)serialization.I would therefore expect in the README.md some rationale on why Kryo is better than that implementation, and how does it compare in regards to performance.
Thanks!
The text was updated successfully, but these errors were encountered: