Avi-Levi / kryo

Automatically exported from code.google.com/p/kryo
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Optimization for objectbuffer #42

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi - 

One suggestion to improve performance of ObjectBuffer on large objects (when at 
runtime its unknown that they're large, so the buffer's initial capacity is 
low) -- Is it possible for the buffer to determine by how much its 
underallocated when it finds that its max capacity is insufficient?  E.g. in 
our case we're Kryoing an object that contains a byte[], and the byte[] is very 
large, but it should be possible for Kryo to know how much extra room it needs, 
and rather than just double the capacity, it could keep doubling until it the 
new allocated amount meets the new allocation requirement.

Hope that makes sense

Thanks! 

Original issue reported on code.google.com by rbakhru@gmail.com on 9 Mar 2011 at 12:28

GoogleCodeExporter commented 9 years ago
Kryo serializers write to a ByteBuffer directly. When the buffer is overrun, it 
throws an exception which unrolls the stack all the way back to the 
ObjectBuffer, where the buffer size is doubled. At this point, there is no way 
to resume serialization where the overrun occurred, so serialization has to 
start from the beginning. The only thing that will really help is to use a 
larger initial buffer size.

The solution to this is to have Kryo not use ByteBuffer directly, but to use a 
Kryo specific buffer class. This would allow the buffer to grow without copying 
and without interrupting serialization (by keeping a list of buffers and 
allocating new ones as needed). It would also allow more flexibility when 
dealing with streams. I've collected a number of ideas for a rewrite of Kryo, 
but don't currently have a timeline.

Original comment by nathan.s...@gmail.com on 9 Mar 2011 at 12:37