.NETのための複数のサイトのテストシリアライザ

SerbenchコードはGitHubの上にあります 。

プロジェクト開始

このベンチマークプロジェクトは、GeeksWithBlogs.netの記事「 .NET v.2のシリアライザー」から始まりました。 記事は、.NETシリアライザのためにほとんど利用できると考えられました。 しかし、この記事と対応するコードを実際のベンチマークに変えるには、いくつかの改善が必要でした。



まず、シリアライザーはいくつかのタイプのデータでテストする必要がありました。 ユニバーサルシリアライザがあり、そこに特化されます。 特殊なものは、ほんの数種類のデータで非常にうまく機能しますが、他のデータでは、機能がはるかに悪くなるか、まったく機能しません。 私たちは、将来的に持っていると確信しました。



第二に、シリアライザは、インターフェイス上で異なります。 私たちのベンチマークは、当社のシリアライザインタフェースに従うように選択を行うべきではありません。 それどころか、ベンチマークは非常に柔軟でなければならず、すべてのシリアライザがそれに最適なインターフェイスを使用できます。 つまり、ベンチマークの特定のシリアライザに追加のパラメータを渡す必要があります。



シリアライザーの1人の著者は、改善されたテストを行うことを提案して、 記事の著者に頼りました。 著者のシリアライザは 、このプロジェクトの創始だった、彼はリード開発者でもありました。 セルゲイは、全体のWebプロジェクトの開発者、すべての偉大なレポートでした。 ベンチマークのプラットフォームとしてNFXが使用されたため、計画されたすべての（および、はるかに）を非常に迅速に行うことができました。 NFXはこのような記事を何百も利用しています。彼もあなたの興味を引くことを願っています。

試験結果の発表

開始するには、私は特別な注意が必要という事実に、結果の提示に少し焦点を当てます。



例として、テストの1つの概要情報を見てみましょう。







左側には、2つの最も重要なカテゴリである3つの勝者が表示されます。速度とシリアル化されたデータの量です。 すぐに私は、受賞者がより多くのすべてのシリアライザは、青、緑と、より少ない程度に、薄茶色のカテゴリの中に閉じ込め、勝者と考えることができますすることができるということを、言います。 グレーカテゴリ - シリアライザは、このテストに合格していません。



コラム速度は、あなたは、シリアライザの名前をクリックすると、シリアル化および逆シリアル化のために別々の番号を解読速度を得ることができます。



シリアル化と逆シリアル化からの最悪の速度が主なものと見なされます。 システム全体のパフォーマンスが重要であり、シリアル化のみまたはデシリアル化のみのパフォーマンスではないことを前提としています。 ケースが異なる場合があるため、別の操作の速度も細い棒でチャートに示されます。

何を探すために：

• シリアライザでテストに合格していません。

一部のテストでは、テストしたほとんどのシリアライザーがデータを失いました。 仕事に「高速」シリアライザを選択し、それがデータを台無しにする場合、これは想像できる最悪の事態です。 歪んだデータの理由を理解しようとすると、多くの時間を費やすことになります。 あなたが開発中ではなく、生産にそれにつまずく場合、あなたは幸運だろう。

• 試験によれば、あなたのデータを満たすために：

推奨事項：ベンチマークコードをダウンロードし、テストデータを変更するか、データを追加して再度テストします。 あなたの直観を決して信用せず、外挿を信用しないでください。 事実上、シリアライザーは特定のデータサイズに分類されます。 リミットテストは実行しませんでした。データについては自分で実行してください。 非常に少数のシリアライザは、すべての我々のテストに合格しました。

注意！

また、本文中に、あなたは常に、「しばしば」など「通常」の言葉に直面することになります 私はこれについて謝罪し、これによりテスト結果が少し曖昧になることを理解しています。 また、テスト結果に最高のシリアライザーが表示されないことを理解していただきたいと思います。 これらは、基礎として使用する必要があるシリアライザーのグループのみを制限します。 あなたはシリアライザのためにあなたのデータを使用します。 したがって、特にこのデータがテストで使用したデータと大きく異なる場合は、YOURデータでテストを実行した後に最終決定を行う必要があります。

注意を払っていないもの：

• テストは数回の数の差を示した場合は、金利の違いに注意を払っていません。 それは無意味でなく、間違っていないだけです。 テストデータをわずかに変更することで、速度やサイズのわずかな変動を簡単に歪めることができます。

試験データ

私たちは、最も使用されるアプリケーションのためのデータを提供することを試みました。 私たちは自分自身の経験に基づいてデータを選択したように、我々は、シリアライザの使用には何の統計情報を持っていません。 重要なものを見逃していることがわかった場合は、お知らせいただくか、テストデータをSerbenchに追加してください。



我々はいくつかの分野で見典型的なアプリケーション：

• 分散、独立したシステム（分散システム）。 プログラムは、異なるプロセス、または異なるマシン、および交換データに独立して動作します。 プログラムは、契約のインターフェースを交換します。 秋のメッセージングシステム（メッセージング）のこのタイプの下で。

データは、このタイプに関連する：代表的な人、テレメトリ、EDI、バッチ。

• 分散、しかし強くシステムを結合。 システムは契約だけでなく、図書館だけでなく通信できることを、以前の場合とは異なり。 ほとんどの場合、これらの関連システムは、一つの場所に設計されています。 秋のRPC（リモートプロシージャコール）システムのこのタイプの下で。

典型的な人、バッチ処理、オブジェクトグラフ：このタイプに関連するデータ。

• ストレージシステム 。 データは、プログラムやデータストア間で転送されます。 以前のケースとの違いは、シリアル化と非シリアル化のサイクルがマイクロ秒または秒以内に発生しないことです。 データは年間保存することができます。 保管契約の期間中に頻繁にバージョン管理データの問題を生じさせる、変更します。 私たちはバージョンで動作するシリアライザをテストしていませんでした。 可能な試験データの任意のストレージ・システムと連携することができます。 しかし、シリアライザは、サポートデータのバージョン管理することを、この場合は、より適切です。

典型的な人

ここでは単純なクラスは、インタフェースなしと継承なしです。 ほとんどすべてのシリアライザは、このテストに合格します。

テレメトリー

同様のデータがIoTを（モノのインターネット）のデバイスを生成しています。 それらの違いは、数値情報、タイムスタンプ、およびいくつかの識別子の可用性です。 時には、データは非常に短い、一の以上の番号に転送する場合、 時々数字を大量に送りました。 シンプルなデータ構造。 ここでは、速度が重要であり、データの充填密度。

エディ

EDI（電子データ交換）データはドキュメントと同等です。 彼らは、複雑な階層構造とネストされたクラスによって特徴づけられます。 クラスのコレクションがあります。

オブジェクトグラフ

オブジェクト指向開発を使用する場合、おそらく同様のクラスを処理する必要がありました。 これらは、クラス間の複雑な関係によって特徴付けられます。 イベントのコレクションを持つConferenceクラスをテストしています。 イベントには、複数の参加者と複数の会議トピックを含めることができます。



興味深いのは、参加者が相手に参照する、いくつかのリンク（リレーションシップ）を、持っているかもしれないということです。 結果は、サイクリック通信です。 これは正常ですが、それは非常に少数のシリアライザは、環状接続で作業することができ判明します。

バッチ処理

あなたは、オブジェクトの複数のコピーを送信する必要がある状況を想像してみてください。 これは、分散システムにおける典型的な状況です。 いくつかのデータ要素を1つのパケットに結合することにより、パケットは1ステップでネットワークを介して送信され、転送を大幅に高速化できます。 パッケージはバッチと呼ばれるため、名前はバッチです。



通常、我々は明示的に特別なクラスのエンベロープ（封筒）のデータ要素を入れて、パッケージを作成する必要があります。 いくつかのシリアライザが大幅に開発を簡素化し、エンベロープの排除を可能にします。

テストプロセス

ここではすべてが簡単です。 1つのテストサイクルで、1つのオブジェクトまたはバッチの場合は多数のオブジェクトをシリアル化し、すぐにそれを逆シリアル化します。 最終ソースオブジェクトとバグを取り除くために比較。 比較は、特定の量で、高速に実行されます。 完全な比較は行いませんが、完全な比較のためのすべてのインターフェイスが利用可能です。



いくつかのテストサイクルが1回の実行にまとめられ、最初にテストデータが生成されます。



いくつかのテストが順番に組み合わされ、最初のテストはウォームアップテストです。 このテストは通常​​1サイクルで構成され、その目的はこのシリアライザーに必要なすべてのオブジェクトを初期化することです。



一部のシリアライザーはすぐに初期化されますが、ゆっくりとシリアル化され、逆もまた同様です。 シリアライザを1回使用する必要がある場合は、ウォームアップテストの結果を無視しないでください。これが主要なテストであるためです。



私たちは通常、最初に単一のオブジェクト、その後、オブジェクトのコレクションをテストしました。 それが判明したように、シリアライザは、コレクションで動作するように最適化することができます。 その後、彼らはリーダーで外部から抜け出すことができます。



任意のデータは、通常それは、コレクションは、エラーのジョブシリアライザまたは結果の急激な減速につながる可能性がある、非常に大きくなる可能性があります。 いくつかのケースでは、不快なシリアライザは、単にシステムを切りました。

試験結果

私たちは、テストですべてのテストの合計のみを受賞者をリストアップ。 個々のテストの勝者は、 サイトのテスト結果ページに非常によく表されています 。 ここでは、いくつかの結論を出します。 私たちは究極の真実を主張せず、数字についてのみコメントするという事実にあなたの注意を集中します。 数字は、今後のテストのアップデートで劇的に変化することができます。

典型的な人

テスト結果 。



このテストでは、私は詳細に説明します。 その他の検査 - 唯一のグランドインチ

すべてのテスト

いるProtobuf、NFXスリム、MsgPack、NetSerializer：ほぼすべてのテストは、同じ最速のシリアライザを明らかにしました。 ウォームアップのテストは、非常に大きな速度の広がりを与えています。 Microsoft BinaryFormatterは、コレクションで優れたパッケージングを示し、1つのサイトで最悪のパッケージングを示しました。 残念ながら、Json.Netはどのテストでもリードを破りませんでした。

ウォームアップテスト（ウォームアップ）

スピード

驚くべき速度の広がりがあります。 NFX Slimは何千もの操作を実行します。たとえば、Jilは1秒間に1つの操作のみを実行します。 シリアライザのバルクは、毎秒一つまたは二つダース操作、時には数十を行います。 さらに驚くべきことに、NFX Slimは約4万5千人を生産しています！ 秒あたりのデシリアライズ。 しかし、我々は、明白な理由のために、唯一の最も遅い操作を考えます。

梱包

スプレッドは、速度ほど大きくありません。 いくつかの受賞者はほぼ同じ結果を示し、JSONシリアライザーは自然に同様の結果を示します。 我々は、具体的JSONシリアライザ（NFX JSON）のいずれかの2つのテストを行いました。 テストの一つは、すべてのインデントと改行、および書式設定のない他のテスト出力をJSONで、素敵な形式のJSONテキストを提供します。 ご覧のとおり、両方のケースのサイズは互いに大きく異なります。



チャンネル内のシリアライズされたデータをフォーマットすることはありません ：この結果は、もう一度、よく知られたルールを確認します！ 唯一のプレゼンテーションと決しての書式行う-転送データに。

バッチ処理

試験結果



ProtoBuf、Microsoft BinaryFormatter、およびNFX Slimのみがシリアル化をシリアル化できます。 この場合は、スリムは、特殊なバッチ処理モードを持っています。



ここでは、さまざまな種類のデータのレートの大きな変動があります。 勝者は、トレーディングおよびEDIクラスのProtoBufから、RPCおよびパーソナルクラスのSlimまでさまざまです。 同時に、ProtoBufは、オブジェクト[]フィールドが検出されたRPCクラスをシリアル化できませんでした。 私たちは、マイクロソフトにBinaryFormatterとNFXスリムに成功し、この試験に合格したことをまとめることができます。 マイクロソフトにBinaryFormatterは、いつものように、彼はエラーなしで働いているという事実を損なわないパッケージにウォームアップとテストの一貫貧しい結果に大きな結果を示しました。

オブジェクトグラフ

テスト結果 。



このテストは、シリアル化が最も難しいことが判明しました。 多くのシリアライザは、それに合格していません。 多くは合格したが、それは恐ろしいスピードとパッケージングを示しました。 ObjectGraph試験でジルは、例えば：会議：1。 参加者：250; イベント：2.6 MWで10パックされたデータ、およびより100平方メートルより少しでパックされたデータの指導者たちは、それが26倍少ないメモリを費やしてきました。



このテストでは、我々は非常に大きなマージンで勝っている少数の指導者たちを見ることができます。 これらは、ProtoBufとNFX Slimです。 マイクロソフトにBinaryFormatterは、突然の包装の程度の指導者たちの間で登場しました。

EDI X12

テスト結果 。



興味深いのは、適切に仕事を終えるためのデータよりシリアライザの容積の増加と方法でした。



ウォームアップテストではいつものように、リーダーはNFX Slimです。



パッケージングのリーダーであるProtoBuf、MsgPack、NetSerializer、NFX Slimは、そのような場合に特別なパッケージング方法を使用しており、これらの方法は非常にうまく機能しているようです。



EDIドキュメントのシリアル化と処理によく使用されるXMLが、XmlSerializerの担当者に、シリアル化されたデータに8〜9倍のスペースを使用して、パッケージングの結果をうんざりさせるという事実に注目します。

シリアライザを選択します

なぜ私たちは、シリアライザを選択する必要がありますか？ .NET Frameworkのシリアライザーを使用して取得できないのはなぜですか？ （Microsoftは、BondやAvroなど、最近登場したいくつかのシリアライザーを提供しています。）



シリアライザは、分散システムのますます重要な要素になってきているという事実。 低速のシリアライザーは最大のパフォーマンスを妨げる可能性があり、高速のシリアライザーは競合他社よりもシステムを改善する可能性があります。 .NETのための新しいシリアライザは今うらやましい恒常で登場します。 それらのそれぞれは、最速としてもてはやされています。 証拠として作成者はテストをリードしています。



我々は独自のテストシステムを開発し、独立した研究を行ってきました。 次に、情報に基づいてシリアライザを選択するのに役立つ基準について説明します。 選択の基準は、テストの結果に基づいています。

信頼性のシリアライズ

私たちは多くのシリアライザは、基本的なテストに合格していないことを見つけるために驚きました。 最高で、我々は最悪の場合、データは無期限に任意の警告またはWindowsのハングせずに失われ、プログラムにエラーが発生します。 中間ケース内のオブジェクトを歪め。



慎重に我々のテストの結果を読み取ります。 これらの結果は、データに大きく依存しています。 データの構造が単純な場合、ほとんどすべてのシリアライザーが仕事をすることができます。 データのサイズが複雑または大きい場合、悲しいかな、それはあまりよくないです。



速度とデータの充填密度は、失われたデータやシステムの応答停止のために言い訳することはほとんどありませんので、私は、信頼性の応力



確かに、最も信頼性の高いシリアライザはあるマイクロソフトにBinaryFormatter 。 彼は最速の一人ではありませんが、これには重要な理由があります。 彼は、エラーなしでほとんどすべてをシリアライズします。

あなたはデータの形式を選択するかどうか？

たとえば、XML形式のパートナーからデータを取得し、あなたがXMLで作業する必要があります。 あなたはこのような状況を変更する方法がありません。 この場合、あなたの選択肢は限られ、XmlSerializerをJson.Netされています。



あなたが他の人のシステムを使用してシステムを統合する場合は、次の選択があなたのために作らされ、あなたはおそらく2つの標準的な形式のいずれかを使用する必要があります：XMLやJSONを。 まれなケースでは、CSV形式または特定のシステムのフォーマットと仕事をしなければなりません。 過去千年のシステムと統合するときに最も頻繁に起こります。



あなたは、このようなint型、ダブル、ブールなどの単純な.NETの型を、シリアライズする必要がある場合は、十分な基本のToString（）関数を持っています。



シリアライザは、JSON形式での作業、より一般的です。 JSONはXMLよりもはるかに単純であり、ほとんどの場合、これは利点です。



多くのシリアライザは、独自のバイナリ形式でデータをパック。 JSON形式は、通常、はるかにコンパクトなXMLを超えています。 バイナリフォーマットは通常、JSONよりもコンパクトです。



あなた自身がデータ形式を選択できる場合、バイナリ・フォーマットは、最良の選択である可能性が高いです。 ただし、この場合、シリアル化と逆シリアル化の両方に同じシリアライザーを使用する必要があることに注意してください。 現時点では、すべてのバイナリ形式は一意であり、いずれも標準化されていません。

データパッキング密度

さらに重要なのは、シリアル化と逆シリアル化の速度またはデータのパッキング密度ですか？



通常、シリアル化されたデータのサイズは、シリアル化-逆シリアル化プロセスの速度よりも重要です。 これは、プロセッサの速度（シリアル化と逆シリアル化を決定する速度）がネットワーク上のデータレートよりもはるかに高いためです。これは通常、送信データのサイズに直接関係します。 データサイズが10％減少すると、データ転送が10％増加し、シリアル化と逆シリアル化の速度が2倍に増加しても1％しか増加しません。

あなたは自分のシステムの最高のパフォーマンスを絞り出すしようとしていますか？ おそらく、あなた開発者の生産性にとってより重要？

例えば、債券、スリフト、船長プロトなどのシリアライザを参照してください。 あなただけの任意のクラスを取り、直列化しません。 あなたはこれらのクラスを記述していないために、特別なIDL言語を使用する必要があります。 通常は、ユーティリティは、クラス自体のクラス定義を生成するのに役立ちます。 しかし、たとえそうであっても、この言語に対処し、開発自体から時間を切り離す必要があります。



他のシリアライザは、例えば、 スリム NFXのは、何もあなたが必要としません。 あなただけの任意のクラスをシリアル化。 中間の場合、直列化可能なクラスは属性で装飾する必要があります。 きっとあなたは、属性[Serializableを]に精通しています。



それが重要なのですか？ はい、それは重要かもしれません。 特に、クラスの構造が自明でない場合。 たとえば、テストシステムには、ネストされた数十のクラスと数百のフィールドで構成されるEDIテストクラスがあります。 これらすべてのクラスとフィールドに属性を追加するのは、面倒で長い仕事でした。



あなたはライブラリ、あなたがアクセスすることはできませんそのコードからクラスをシリアル化するときしかし、それは重要です。 コードを取得してそこに属性を追加することはできません。コードは使用できません。 多くの場合、この状況を回避するために、プログラマーはいわゆるDTO（ データ転送オブジェクト ）を使用します。 これらの使用は、プログラムの複雑さと開発の秋の速さに満ちています。 代わりに、ビジネスロジックに取り組んで、あなたはそれとは関係のないコードを記述する必要があります。

あなたは、シリアライズするとデシリアライズするシリアライザを選択するか、またはこれらの操作の一つだけ？

システムが受信側または送信側のみである場合は、同意する必要があります。これは、両方の操作を担当する場合とは異なります。

あなたのデータ収集ではありますか？

シリアライザはオブジェクトのコレクションで動作するように最適化することができます。 他のシリアライザーは、コレクションを決して区別しないため、速度とパッケージングがはるかに悪くなります。

あなたのデータのサイズは？

データは非常に大きくなる可能性があり、シリアライザの急激な速度低下やシリアル化エラーを引き起こす可能性があります。 シリアライザは、単純にシステムがハングアップすることができます。



メモリ内の大規模なデータは、順番に、長いストライキプログラムを引き起こす可能性があり、ガベージコレクションを、影響を与えることができます。

あなたは非常に珍しい何かをシリアル化する必要がありますか？

そして、ここであなたはこのタスクを正確に専門とするシリアライザーによって助けられます。 たとえば、 Linq式を処理するシリアライザー 。

あなたは超スーパーパフォーマンスが必要ですか？

そして、最良のオプションは、あなた自身の専門性の高いシリアライザを書くことであろう。



あなたがそれを行うにはしたくない場合は、別のシリアライザで使用される追加の方法に注意を払います。 例えば、 バッチ処理速度を高めるための優れた方法です。 残念ながら、わずか数シリアライザは、任意の追加のコーディングなしでそれを使用することができます。



並列シリアル化は 、高速を達成するための優れた方法でもあります。 あなたはそれを使用している場合は、 スレッドセーフシリアライザあなたにとって重要です。