I thought about that so I did multiple runs of each serialization method in a
row. Here are the results of running multiple runs in a row for Thrift and
protocol buffers.
, Object create, Serialization, Deserialization,
Total Time, Serialized Size
thrift , 236.12000, 7585.00000, 6664.00000,
14485.12000, 220
thrift , 235.90500, 7222.50000, 6709.50000,
14167.90500, 220
thrift , 237.42500, 7381.50000, 6688.50000,
14307.42500, 220
thrift , 234.52500, 10247.50000, 6665.50000,
17147.52500, 220
thrift , 241.17000, 7336.50000, 6666.50000,
14244.17000, 220
thrift , 235.93500, 9966.50000, 6683.00000,
16885.43500, 220
thrift , 236.10000, 7133.00000, 6660.50000,
14029.60000, 220
thrift , 235.43000, 10715.00000, 6660.50000,
17610.93000, 220
thrift , 233.83000, 10384.50000, 6690.50000,
17308.83000, 220
protobuf , 375.61000, 10807.00000, 4895.00000,
16077.61000, 217
protobuf , 383.19000, 7112.00000, 5039.50000,
12534.69000, 217
protobuf , 382.63000, 7166.50000, 4857.50000,
12406.63000, 217
protobuf , 375.37000, 9521.50000, 4895.00000,
14791.87000, 217
protobuf , 376.77000, 11855.00000, 4817.00000,
17048.77000, 217
protobuf , 373.11000, 10333.50000, 4854.50000,
15561.11000, 217
I suspect it may have something to do with GC but haven't proved that out yet.
Notice that serialization time is highly variable but deserialization time is
almost constant.
Any thoughts?
Chad
On 5/14/09 9:49 PM, "Doug Cutting" <[email protected]> wrote:
Chad Walters wrote:
> 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.
Are you throwing away the first run of each benchmark in a given JVM?
I've found that to greatly stabilize many Java benchmarks.
Doug
