I am not sure that the JVM can kick in any further optimizations - repeated
runs of 10000 serializations and deserializations seem to me like they should
trigger anything that could feasibly be done.
I was able to get results as follows by making some minor mods to TMemoryBuffer
and then making use of that via some changes to the test's ThriftSerializer and
BenchmarkRunner (and using TCompactProtocol again of course):
, Create, Ser, Deser, Total, Size
thrift , 265.73, 11287.50, 6813.50, 18366.73, 220
thrift , 266.33, 10385.50, 6784.00, 17435.83, 220
thrift , 262.85, 8589.50, 6833.00, 15685.35, 220
thrift , 266.49, 9415.50, 6903.50, 16585.49, 220
thrift , 266.21, 10587.00, 6873.00, 17726.21, 220
thrift , 267.14, 7478.50, 6911.50, 14657.14, 220
protobuf , 416.11, 11679.00, 4982.50, 17077.61, 217
protobuf , 438.74, 8211.00, 5434.00, 14083.74, 217
protobuf , 419.93, 11504.00, 5403.50, 17327.43, 217
Deserialization is still slower than protobuf but it is closer. Essentially,
the speedups come from not creating new transports and protocols each request.
The way the test works kind of messes with Thrift's transport model on
deserialization. The test serializes once and then deserializes from that array
10000 times - but Thrift consumes the bytes.
So I had to move the serialization into the loop but outside the timer and also
reset the TMemoryBuffer at the start of serialization so that I could reuse the
TMemoryBuffer over and over again.
I can't yet explain why the serialization time can range from ~7500 to ~12000
at times, but it bounces around for protocol buffers too.
Still more digging to do...
Chad
On 5/12/09 12:50 PM, "David Reiss" <[email protected]> wrote:
> Looking a little further at deserialization since Thrift seemed to be
> performing worse than protocol buffers there, the problem may be related to
> the fact that protocol buffers provides APIs that support direct
> serialization to and deserialization from byte arrays which Thrift does not
> provide. The test harness is set up such that the output of serialize() and
> the input of deserialize() is a byte array, so this means that Thrift needs
> to do more work to match up with the test harness. I am still investigating
> this.
My hope is that if you run the benchmark multiple times before the actual run
that you examine, the n will notice that read and write are often being called
with a TCompactProtocol and TMemoryBuffer and inline the calls.
--David
