.Netシリアル化で発生した問題を診断および解決するための適切なパフォーマンス評価

親愛なる読者！ Scott Hanselmanによる「 .NETシリアル化のボトルネックを診断して解決するための適切なベンチマーク 」というタイトルの記事の翻訳を紹介します 。



はじめに、いくつかの予約とコメント。 まず、パフォーマンス評価プロセスは複雑です。 測定が難しい。 しかし、実際の問題は、しばしば何かのパフォーマンスを評価する理由を忘れることです。 私たちは複雑なマルチマシン金融システムを採用し、突然シリアル化を実行するコードに非常に集中しますが、これが問題だと考えています。 「10,000反復のforループを記述し、実行時間をxミリ秒短縮することでこのシリアル化を最適化できれば、すべてがうまくいきます。」



第二に、これはパフォーマンス比較結果の投稿ではありません。 それを参照せず、「見て！ XライブラリはYライブラリよりも優れています。または.NetはJavaよりも優れています！」代わりに、有益なストーリーと一連の一般的なガイドラインと見なしてください。 私はこのストーリーを次の点を強調するために使用します。

• 測定対象を100％理解していますか？
• Visual Studioプロファイラー、ANTS、または.dotTraceなどのプロファイラーを実行しましたか？
• ウォームアップ時間を考慮していますか？ 明確に区別された測定値を破棄しますか？ 結果は統計的に有意ですか？
• 使用するライブラリはユースケースに最適化されていますか？ あなたのユースケースが何であるか知っていますか？

1つの悪いパフォーマンススコア

最近、ある読者が.Netでのシリアル化に関する質問をメールで送ってきました。 彼らは 2009年にグラフやチャートを含む生産性に関する非常に古い記事を読み、独立していくつかのテストを実施しました。 彼らは、シリアル化時間（数万要素）が700ミリ秒を超え、ボリュームが約2メガバイトであることを記録しました。 このテストでは、一連の異なるライブラリを使用して、C＃とJavaの両方で典型的なデータ構造をシリアル化しました。 ライブラリには、自社のシリアライザー、バイナリ.Net DataContract、およびJSON.NETが含まれていました。 あるケースでは、シリアル化により少量のデータ（大きな構造の場合は1.8 MB）が得られ、別のケースでは、高速に（94ミリ秒）動作しましたが、明らかな勝者はいませんでした。 読者は気を失いそうになり、ある意味では、.Netを使用して問題を解決すべきではないと判断しました。



私の意見では、このパフォーマンス評価には何か問題があります。 何が測定されていたかは明らかではありません。 測定が信頼できるものであったかどうかは明確ではありません。具体的には、「。Netは遅い」という普遍的な結論は、提示されたデータを考慮すると正当化されませんでした。



うーん...それは.Netは何万ものデータ構造をすばやくシリアル化できないのですか？ 私はそれができることを知っています。

参照： 価値のあるベンチマークと結果の作成 、 @ Kellabyteによる責任あるベンチマーク

私は専門家ではありませんが、このコードを少し試してみました。

最初に：私たちは正しく測定していますか？

テストではDateTime.UtcNowを使用しましたが、このような場合の使用は推奨されていません。

startTime = DateTime.UtcNow; resultData = TestSerialization(foo); endTime = DateTime.UtcNow;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

精度が必要な測定には、DateTime.NowまたはDateTime.Utcを使用しないでください。 DateTimeには十分な精度がなく 、最大30msのエラーで時間を返します 。



DateTimeは日付と時刻を表します。 これは、精密タイマーやストップウォッチではありません。



エリック・リッパートが言うように ：

一言で言えば、「今は何時ですか？」そして「これはどのくらい続いているのですか？」まったく異なる質問です。 ある質問に答えて別の質問に答えるように設計されたツールを使用しないでください。

そしてレイモンド・チェンが言うように ：

精度は精度と同じではありません。 信頼性とは、正しい答えにどれだけ近いかということです。 精度-特定の応答の解像度。

そのため、ストップウォッチが必要な場所ではストップウォッチを使用します。 サンプルをストップウォッチに変換する前に、90,106,103,165,94のようなミリ秒単位の値を取得し、ストップウォッチに切り替えた後、結果は99,94,95,95,94でした。 値の変動はずっと小さくなりました。

 Stopwatch sw = new Stopwatch(); sw.Start(); // stuff sw.Stop();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、パフォーマンスの信頼できる推定値を取得しようとしている場合は、プロセスを単一のプロセッサコアにバインドする必要があります。 それは問題ではなく、StopwatchはWin32 QueryPerformanceCounter（.NetのStopwatchのソースコードはこちら ）を使用しますが、テストが1つのプロセッサーで開始され、別のプロセッサーで終了した場合、古いシステムでいくつかの問題がありました 。

 // One Core var p = Process.GetCurrentProcess(); p.ProcessorAffinity = (IntPtr)1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ストップウォッチを使用していない場合は、パフォーマンスを評価するためのシンプルで最適なライブラリを探してください。

2番目：結果を数える

与えられたサンプルコードでは、約10行に実際の測定値が含まれ、735行に「インフラストラクチャ」が含まれていて、受信データの収集と表示を担当しています。 これは前に見ましたか？ 「インフラストラクチャ」ではパフォーマンス評価が失われる可能性があると言っても過言ではありません。



「 パフォーマンスとしてのパフォーマンス 」に関する最近のMatt Warrenポッドキャストを聞いて、 Mattのパフォーマンスブログを ご覧ください。BenWatsonの「 Writing High Performance .NET Code 」というタイトルの本を必ずお読みください 。



また、Mattは現在、GitHubのパフォーマンスを評価するためのコンパクトなインフラストラクチャの作成を試行していることに留意してください。 このシステムは非常に有望であり、単体テスト内で直接[ベンチマーク]属性を適用する評価プロセスを減らすことができます 。



単純なパフォーマンス評価のために既存のインフラストラクチャを使用することを検討してください。 それらの1つはYan Cuiの SimpleSpeedTesterです。 彼女は素敵な錠剤を作り、あなたのために多くの退屈な仕事をします。 Yanのブログで盗んだスクリーンショットを以下に示します。









見る価値のあるもう少し高度なツールは、「遅延とパフォーマンスに敏感なアプリケーションで測定値のヒストグラムを記録するように設計された」ライブラリであるHdrHistogramです。 また、GitHubにもあり、Java、C、およびC＃での実装が含まれています。









そして真剣に。 プロファイラーを使用します。

3番目：プロファイラーを実行しましたか？

Visual Studio Profilerを使用するか、 Redgate ANTS Performance ProfilerまたはJetBrains dotTraceプロファイラートライアルをダウンロードします。



アプリケーションは何に時間を費やしますか？ プロファイラを開始するだけでなく、複雑なテストを行い、ブラックボックスの作業を研究した人々に出会ったと思います。

ところで、問題を解決するための新しい/適切な/研究された方法はありますか？

これは私の意見ですが、注目に値し、それを証明する数字があると思います。 .Netでシリアル化を実行するコードの一部は非常に古く、2003年または2005年に記述されており、新しい技術や知識を活用できない場合があります。 さらに、これは非常に高度に特殊化されたコードとは対照的に、かなり柔軟で「すべての人に適した」コードです。



人々は、シリアル化に関連するさまざまなニーズを持っています。 何かをXMLにシリアル化し、結果が小さくコンパクトになると期待することはできません。 同様に、構造をJSONにシリアル化し、バイナリシリアル化と同じくらい高速であることを期待することはできません。



コードを測定し、要件を分析し、一歩下がってすべてのオプションを検討します。

4番目：検討に値する新しい.Netシリアライザー

何が起こっているのか、そして費やされた時間をどのように測定するのかが理解できたので、これらすべてのシリアライザが読者の目標を達成していないことが明らかになりました。 私が言ったように、いくつかはずっと前に書かれています。 では、より高度で現代的なオプションは何ですか？



注目すべき2つの本当に優れたシリアライザーがあります。 これはKevin MontroseのJilとMarc Gravellのprotobuf-netです 。 どちらも素晴らしいです。サポートされているフレームワークとprotobuf-netビルドシステムのカバー範囲は目が痛いだけです。 また、 ServiceStack.NETには、JSONだけでなくJSVおよびCSVのサポートを含む、他の印象的なシリアライザーもあります。

Protobuf-net-.NETのプロトコルバッファー

プロトコルバッファはGoogleのデータ構造記述形式であり、protobuf-netは.NETでのプロトコルバッファの高性能実装です。 これがXMLであり、よりコンパクトで高速であることを想像してください。 さらに、言語間のシリアル化の可能性があります。 彼らのウェブサイトに示されているものは次のとおりです。

プロトコルバッファには、XMLで構造化データをシリアル化するよりも多くの利点があります。 それらは：

• 簡単に
• 3〜10倍少ない
• 20から100倍高速
• より明確な
• プログラムコードで使いやすいデータアクセスクラスを生成する

追加するのは簡単でした。 データ構造を装飾するには多くの方法がありますが、基本的には次のとおりです。

 var r = ProtoBuf.Serializer.Deserialize<List<DataItem>>(memInStream);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

protobuf-netで得た数値は例外的でした。この場合、データは49ミリ秒で、タイトかつ迅速に圧縮されました。

JIL-Sigilを使用した.NET用のJSONシリアライザー

JilはJsonシリアライザーであり、Json.netほど柔軟性がありませんが、速度の名目でこの小さな犠牲が彼らに与えられています。 彼らが言うことは次のとおりです。

柔軟性と「クールな機能」は、速度を追求する際に明示的に無視されます

また、一部のシリアライザーはメモリ内の文字列を処理しますが、Json.NETやDataContractSerializerなどの他のシリアライザーはストリームを処理します。 これは、ライブラリを選択するときに、シリアル化するサイズを考慮する必要があることを意味します。



Jilは多くの人にとって印象的ですが、特に（XmlSerializersが一度行ったように）動的にカスタムシリアライザーを生成するためです。



Jilは非常に使いやすいです。 それだけで動作します。 例として追加し、84msでシリアル化しました。

 result = Jil.JSON.Deserialize<Foo>(jsonData);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論：パフォーマンスの比較はそれほど単純ではありません

何を測定していますか？ なぜこれを測定するのですか？ あなたの方法はユースケースに適していますか？ 1つの大きなオブジェクトまたは何千もの小さなオブジェクトをシリアル化しますか？



ジェームズ・ニュートン・キングは私に一つの素晴らしい考えをもたらしました：

「パフォーマンスの比較に関連するメタ問題があります。重要ではないパフォーマンスの微調整とケアは、多くの開発者の罪です。ドキュメント、開発者の生産性、柔軟性は100分の1ミリ秒よりも重要です。」 」

ジェームズは、Twitterの古い（しかし最近修正された）ASP.NETバグを指摘しました。 これはパフォーマンスに影響を与える重要なエラーですが、それでもネットワークを介したデータの送信に費やされた時間の観点からは消えていきます。

このエラーは、多くの開発者が重要ではないときにパフォーマンスを気にするという考えを裏付けています。

- ジェームズ・ニュートン・キング（@JamesNK）2015年2月13日

この投稿の準備に協力してくれたMarc GravellとJames Newton-Kingに感謝します。



元の記事はこのリンクから入手できます。