Ric*_*son 15 c++ protocol-buffers flatbuffers capnproto
我决定找出 Protobuf、Flatbuffers 和 Cap'n proto 中的哪一个是我的应用程序最好/最快的序列化。在我的情况下,通过网络发送某种字节/字符数组(我序列化为该格式的原因)。所以我对所有三个都做了简单的实现,其中我对一个字符串、一个浮点数和一个整数进行了序列化和反序列化。这给出了意想不到的结果:Protobuf 是最快的。我会称它们为意外,因为 cap'n proto 和 flatbuffes 都“声称”是更快的选择。在我接受这一点之前,我想看看我是否无意中在我的代码中作弊。如果我没有作弊,我想知道为什么 protobuf 更快(究竟为什么可能是不可能的)。对于 cap'n proto 和 faltbuffers 来说,这些消息是否可以简单到真正让它们大放异彩?
我的时间:
flatbuffers 所用
时间:14162 微秒 capnp 所用
时间:60259 微秒protobuf 所用时间:12131 微秒
(显然这些取决于我的机器,但重要的是相对时间)
平面缓冲区代码:
int main (int argc, char *argv[]){
std::string s = "string";
float f = 3.14;
int i = 1337;
std::string s_r;
float f_r;
int i_r;
flatbuffers::FlatBufferBuilder message_sender;
int steps = 10000;
auto start = high_resolution_clock::now();
for (int j = 0; j < steps; j++){
auto autostring = message_sender.CreateString(s);
auto encoded_message = CreateTestmessage(message_sender, autostring, f, i);
message_sender.Finish(encoded_message);
uint8_t *buf = message_sender.GetBufferPointer();
int size = message_sender.GetSize();
message_sender.Clear();
//Send stuffs
//Receive stuffs
auto recieved_message = GetTestmessage(buf);
s_r = recieved_message->string_()->str();
f_r = recieved_message->float_();
i_r = recieved_message->int_();
}
auto stop = high_resolution_clock::now();
auto duration = duration_cast<microseconds>(stop - start);
cout << "Time taken flatbuffer: " << duration.count() << " microseconds" << endl;
return 0;
}
Run Code Online (Sandbox Code Playgroud)
cap'n 原型代码:
int main (int argc, char *argv[]){
char s[] = "string";
float f = 3.14;
int i = 1337;
const char * s_r;
float f_r;
int i_r;
::capnp::MallocMessageBuilder message_builder;
Testmessage::Builder message = message_builder.initRoot<Testmessage>();
int steps = 10000;
auto start = high_resolution_clock::now();
for (int j = 0; j < steps; j++){
//Encodeing
message.setString(s);
message.setFloat(f);
message.setInt(i);
kj::Array<capnp::word> encoded_array = capnp::messageToFlatArray(message_builder);
kj::ArrayPtr<char> encoded_array_ptr = encoded_array.asChars();
char * encoded_char_array = encoded_array_ptr.begin();
size_t size = encoded_array_ptr.size();
//Send stuffs
//Receive stuffs
//Decodeing
kj::ArrayPtr<capnp::word> received_array = kj::ArrayPtr<capnp::word>(reinterpret_cast<capnp::word*>(encoded_char_array), size/sizeof(capnp::word));
::capnp::FlatArrayMessageReader message_receiver_builder(received_array);
Testmessage::Reader message_receiver = message_receiver_builder.getRoot<Testmessage>();
s_r = message_receiver.getString().cStr();
f_r = message_receiver.getFloat();
i_r = message_receiver.getInt();
}
auto stop = high_resolution_clock::now();
auto duration = duration_cast<microseconds>(stop - start);
cout << "Time taken capnp: " << duration.count() << " microseconds" << endl;
return 0;
}
Run Code Online (Sandbox Code Playgroud)
protobuf 代码:
int main (int argc, char *argv[]){
std::string s = "string";
float f = 3.14;
int i = 1337;
std::string s_r;
float f_r;
int i_r;
Testmessage message_sender;
Testmessage message_receiver;
int steps = 10000;
auto start = high_resolution_clock::now();
for (int j = 0; j < steps; j++){
message_sender.set_string(s);
message_sender.set_float_m(f);
message_sender.set_int_m(i);
int len = message_sender.ByteSize();
char encoded_message[len];
message_sender.SerializeToArray(encoded_message, len);
message_sender.Clear();
//Send stuffs
//Receive stuffs
message_receiver.ParseFromArray(encoded_message, len);
s_r = message_receiver.string();
f_r = message_receiver.float_m();
i_r = message_receiver.int_m();
message_receiver.Clear();
}
auto stop = high_resolution_clock::now();
auto duration = duration_cast<microseconds>(stop - start);
cout << "Time taken protobuf: " << duration.count() << " microseconds" << endl;
return 0;
}
Run Code Online (Sandbox Code Playgroud)
不包括消息定义文件,因为它们很简单并且很可能与它无关。
Ken*_*rda 39
在头儿原,你应该不重复使用MessageBuilder的多条消息。按照您编写代码的方式,循环的每次迭代都会使消息更大,因为您实际上是在添加现有消息而不是开始新消息。为了避免每次迭代时分配内存,您应该将临时缓冲区传递给MallocMessageBuilder的构造函数。临时缓冲区可以在循环外分配一次,但MallocMessageBuilder每次循环都需要创建一个新缓冲区。(当然,大多数人不会为临时缓冲区而烦恼,只是让MallocMessageBuilder自己进行分配,但是如果您在此基准测试中选择该路径,那么您还应该更改 Protobuf 基准测试为每次迭代创建一个新的消息对象,而不是重用单个对象。)
此外,您的 Cap'n Proto 代码正在使用capnp::messageToFlatArray(),它分配一个全新的缓冲区来将消息放入并复制整个消息。这不是使用 Cap'n Proto 的最有效方法。通常,如果您将消息写入文件或套接字,您将直接从消息的原始后备缓冲区写入而不进行此副本。尝试这样做:
kj::ArrayPtr<const kj::ArrayPtr<const capnp::word>> segments =
message_builder.getSegmentsForOutput();
// Send segments
// Receive segments
capnp::SegmentArrayMessageReader message_receiver_builder(segments);
Run Code Online (Sandbox Code Playgroud)
或者,为了使事情更真实,您可以将消息写到管道中,然后使用capnp::writeMessageToFd()和 将其读回capnp::StreamFdMessageReader。(公平地说,您还需要使 protobuf 基准测试写入/读取管道。)
(我是 Cap'n Proto 和 Protobuf v2 的作者。我不熟悉 FlatBuffers 所以我无法评论该代码是否有任何类似的问题......)
我花了很多时间对 Protobuf 和 Cap'n Proto 进行基准测试。我在这个过程中学到的一件事是,您可以创建的大多数简单基准都不会为您提供现实的结果。
首先,在正确的基准测试案例中,任何序列化格式(甚至 JSON)都可以“获胜”。不同的格式会根据内容的不同表现非常非常不同。它是字符串重、数字重还是对象重(即具有深度消息树)?不同的格式在这里有不同的优势(例如,Cap'n Proto 非常擅长数字,因为它根本不转换它们;JSON 在它们方面非常糟糕)。您的消息大小是非常短、中等还是非常大?短消息将主要执行设置/拆卸代码而不是正文处理(但设置/拆卸很重要——有时现实世界的用例涉及大量小消息!)。非常大的消息会破坏 L1/L2/L3 缓存并告诉您更多有关内存带宽的信息而不是解析复杂性(但同样,
即使考虑了所有这些,您还有另一个问题:在循环中运行代码实际上并没有告诉您它在现实世界中的执行情况。在紧密循环中运行时,指令缓存保持热状态,所有分支都变得高度可预测。因此,分支密集型序列化(如 protobuf)的分支成本将被掩盖,而代码足迹密集型序列化(再次......如 protobuf)也将获得优势。这就是为什么微基准测试仅在将代码与自身的其他版本进行比较时才真正有用(例如,测试次要优化),而不是将完全不同的代码库相互比较。要了解其中任何一项在现实世界中的表现,您需要端到端地衡量现实世界的用例。但是……老实说,这很难。