I’ve used Thrift for some log client in our system. I’m going to use Protocol Buffers as the internal communication protocol between our XMPP servers. But I am hard to believe from the thrift and protocol buffers Python performance comparison, that that Protocol Buffers is 4-10 slower than Thrift. I’m going to do some similar tests on Java.
The test is very similiar as the Python test. the .proto and .thrift file are copied from the above python test.
The .thrift content:
struct dns_record {
1: string key,
2: string value,
3: string type = 'A',
4: i32 ttl = 86400,
5: string first,
6: string last
}
typedef list<dns_record> biglist
struct dns_response {
1: biglist records
}
service PassiveDns {
biglist search_question(1:string q);
biglist search_answer(1:string q);
}
The .proto content
package passive_dns;
message DnsRecord {
required string key = 1;
required string value = 2;
required string first = 3;
required string last = 4;
optional string type = 5 [default = "A"];
optional int32 ttl = 6 [default = 86400];
}
message DnsResponse {
repeated DnsRecord records = 1;
}
From the document, I learn that the optional and default values are one of the benefits of both serialization libraries. A record that matches the default value does not need to be included in the serialized output.
I wrote up a simple test program to compare thrift, protocol buffers. I tested the serialize and deserialize together, because this is the most called part in most scenarioes.
Test 1: 10,000,000 times
ProtoBuf Loop : 10,000,000 Get object : 15,130msec Serdes protobuf: 68,600msec Objs per second: 145,772 Total bytes : 829,996,683 Thrift Loop : 10,000,000 Get object : 12,651msec Serdes thrift : 36,904msec Objs per second: 270,973 Total bytes : 1,130,000,000
Test 2: 1,000,000 times
ProtoBuf Loop : 1,000,000 Get object : 1,094msec Serdes protobuf: 7,467msec Objs per second: 133,922 Total bytes : 83,000,419 Thrift Loop : 1,000,000 Get object : 524msec Serdes thrift : 5,969msec Objs per second: 167,532 Total bytes : 113,000,000
The serde_* functions are the times needed to serialize, and de-serialize the java object to and from a byte[].
The result in Java was that Protocol Buffers 1.2-2 times slower than Thrift. (in the python test was 4~10 times). And PB binary size is smaller than Thrift. I think this is acceptable, and Google may improve the Protocol Buffers performance in the future version.
Download my test code in Java: thrift-protocol-buffers-java.tgz,
More information about thrift and protocol buffers: Thrift, Protocol Buffers installation and Java code howto
Update: There is another Thrift vs. Protocol Buffers compare non-performance factors.
UPDATE 2 (Apr 17): There is a performance tuning parameter optimize_for = SPEED (thanks Steve Chu) for Protocol Buffers, please see my next performance tests Thrift and Protocol Buffers performance in Java Round 2
