プロジェクトで RPC フレームワークとして thrift を使用することを既に選択しています。このプロジェクトには、多くのシリアル化/逆シリアル化操作 (データをディスクに保存するなど) があります。また、シリアル化された形式は、少なくとも C++/Java/Python でアクセスできる必要があります。thrift のシリアル化ソリューションは、Protobuf よりも複雑なようです (たとえば、オブジェクトをシリアル化する前にプロトコルを作成する必要があります)。
だから私の質問は: 倹約がこのタスクを実行できる場合でも、シリアライゼーション/デシリアライゼーションの部分に Protobuf を使用する価値はありますか?
Protobuf RPC よりもクロスランゲージ RPC には Thrift の方が適していることに同意します ( http://pjklauser.wordpress.com/2013/02/27/why-googles-protobuf-rpc-will-not-reach-widespread-を参照)。採用/）。すでに倹約を使用している場合、ファイル/ストレージへのシリアル化に別の「ライブラリ」を使用することを正当化することは困難です。無限のマッピング コードを記述する必要があります。両方のライブラリには異なるメンテナンス サイクルがあり、個別にメンテナンスする必要があるため、将来的に余分な労力がかかります。1 行または 2 行のコードをさらに記述したり、1 バイトまたは 2 バイトのスペースを節約したり、CPU 時間を 1 マイクロ秒節約したりするためのコストは、追加の労力に比べれば何でもありません。