eishay / jvm-serializers

Benchmark comparing serialization libraries on the JVM
http://groups.google.com/group/java-serialization-benchmarking
3.28k stars 561 forks source link

buffers #23

Closed ikabiljo closed 12 years ago

ikabiljo commented 12 years ago

Some serializers initialize buffer they need in the constructor, and reuse it in every call (Kryo, Protostuff, etc), and some create a new buffer each time object is serialized (all that use outputStream function, Wobly, maybe some others).

All serializers should probably be either using one initialized buffer, or creating new buffer each time. This change changes outputStream function not to create buffer each time, and does the same thing for Wobly.(though it probably doesn't cover all serializers that currently create a buffer each time).

dyu commented 12 years ago

That's right. That was one of the reasons why protostuff had to resort to also cache the buffer since kryo was doing it from the beginning. Still, your patch doesn't cover all serializers. Protobuf for example internally allocates the buffer ... hence it cannot re-use the buffer.

What I propose would be to cache nothing at all. Instead of refactoring all the others, kryo and protostuff should be the ones refactored to not cache.

ikabiljo commented 12 years ago

I think reusing of the buffer is little more preferable - since I think it is more closer to actual usage. If you care about the speed - you will probably either have ThreadLocal buffer or a buffer pool of large enough size. If some library doesn't have option to use cached buffer - it is fair that test shows that. Also, some serializers are using buffers that are re-sizable, and some that are not re-sizable, which makes it a little difficult to create the same conditions for all if buffers are not reusable.

Though I am not strongly in favor of either side, just that they should be equal. :)

dyu commented 12 years ago

" just that they should be equal. :)" The only way to equal everything is to uncache everything.