リフレクションの加速に関する失敗した記事

早速記事タイトルを説明していきます。当初の計画では、シンプルだが現実的な例を使用して、リフレクションの使用を高速化するための適切で信頼できるアドバイスを提供する予定でしたが、ベンチマーク中に、リフレクションは思ったほど遅くなく、悪夢よりも LINQ が遅いことが判明しました。しかし、結局のところ、私も寸法を間違えていたことが判明しました... この人生の物語の詳細はカットの下とコメントにあります。この例は非常にありふれたものであり、原則として企業で通常行われているように実装されているため、人生のデモンストレーションとして非常に興味深いものであることがわかりました。記事の主要な主題の速度への影響は次のとおりです。外部ロジック (Moq、Autofac、EF Core、その他の「バンディング」) のため目立ちません。

私はこの記事を読んで次のような印象を受けて仕事を始めました。 リフレクションが遅いのはなぜですか

ご覧のとおり、作成者は、アプリケーションを大幅に高速化する優れた方法として、リフレクション型メソッドを直接呼び出すのではなく、コンパイルされたデリゲートを使用することを提案しています。もちろん、IL の放出はありますが、これはタスクを実行するための最も労働集約的な方法であり、エラーが多いため、これは避けたいと考えています。

私も反射の速さについては常に同様の意見を持っていたことを考慮すると、特に著者の結論に疑問を呈するつもりはありませんでした。

企業内でリフレクションが単純に使用されていることによく遭遇します。型が取られています。物件に関する情報を取得します。 SetValue メソッドが呼び出され、全員が喜びます。目的のフィールドに値が到着し、誰もが満足しています。非常に賢い人たち、つまり上級者やチームリーダーは、あるタイプから別のタイプへのこのような単純な実装の「ユニバーサル」マッパーに基づいて、オブジェクトへの拡張機能を作成します。通常、本質は次のとおりです。すべてのフィールドを取得し、すべてのプロパティを取得して、それらを反復処理します。型メンバーの名前が一致する場合は、SetValue を実行します。場合によっては、型の 1 つで何らかのプロパティが見つからなかったという間違いによる例外が発生することがありますが、ここでもパフォーマンスを向上させる方法があります。試して/捕まえてください。

以前のマシンがどのように動作するかについての情報を十分に持たずに、パーサーやマッパーを再発明する人々を見てきました。私は、あたかも後続のバカバカしさを言い訳にするかのように、素朴な実装を戦略の背後、インターフェースの背後、インジェクションの背後に隠す人々を見てきました。私はそのような認識に鼻を鳴らしました。実際、私は実際のパフォーマンス リークを測定したわけではなく、可能であれば、実装を入手できれば、より「最適な」実装に変更しただけです。したがって、以下で説明する最初の測定値は私をひどく混乱させました。

リヒターや他のイデオロギー論者を読んでいる多くの人は、コード内のリフレクションはアプリケーションのパフォーマンスに非常に悪影響を与える現象であるという完全に公平な声明に出会ったことがあると思います。

リフレクションを呼び出すと、CLR はアセンブリを通過して必要なアセンブリを見つけたり、メタデータを取得したり、解析したりする必要があります。さらに、シーケンスをトラバースする際のリフレクションにより、大量のメモリが割り当てられます。メモリを使い果たしており、CLR が GC を発見し、フリーズが始まります。信じてください、かなり遅くなるはずです。最新の実稼働サーバーやクラウド マシンに大量のメモリが搭載されていても、処理の大幅な遅延は避けられません。実際、メモリが多いほど、GC がどのように動作するかに気づく可能性が高くなります。理論上、彼にとって反省は余計な雑巾のようなものである。

ただし、私たちは皆 IoC コンテナーと日付マッパーを使用しており、その動作原理もリフレクションに基づいていますが、通常、それらのパフォーマンスについて疑問はありません。いいえ、依存関係の導入と外部の限定されたコンテキスト モデルからの抽象化が非常に必要であるため、いずれにしてもパフォーマンスを犠牲にしなければならないからではありません。すべてがシンプルなので、パフォーマンスにはあまり影響しません。

実際、リフレクション テクノロジに基づく最も一般的なフレームワークは、リフレクション テクノロジをより最適に操作するためにあらゆる種類のトリックを使用しています。通常、これはキャッシュです。通常、これらは式ツリーからコンパイルされた式とデリゲートです。同じオートマッパーは、リフレクションを呼び出さずに型を別の型に変換できる関数と型を照合する競合辞書を維持します。

これはどのようにして達成されるのでしょうか?基本的に、これはプラットフォーム自体が JIT コードを生成するために使用するロジックと何ら変わりません。メソッドが初めて呼び出されるとき、そのメソッドはコンパイルされます (そして、確かに、このプロセスは高速ではありません)。その後の呼び出しでは、制御は既にコンパイルされたメソッドに移されるため、パフォーマンスが大幅に低下することはありません。

この例では、JIT コンパイルを使用して、コンパイルされた動作を対応する AOT と同じパフォーマンスで使用することもできます。この場合、式が役に立ちます。

問題の原則は次のように簡単に定式化できます。
リフレクションの最終結果は、コンパイルされた関数を含むデリゲートとしてキャッシュする必要があります。また、必要なすべてのオブジェクトを、オブジェクトの外部に格納されている型 (ワーカー) のフィールドに型情報とともにキャッシュすることも意味があります。

これには論理があります。常識的には、何かをコンパイルしてキャッシュできる場合は、それを実行する必要があります。

今後のことを考えると、提案された式のコンパイル方法を使用しない場合でも、リフレクションを使用するキャッシュには利点があると言えます。実際、ここでは私が上で参照した記事の著者の主張を繰り返しているだけです。

次にコードについてです。深刻な信用機関の本格的な制作で私が直面しなければならなかった最近の痛みに基づいた例を見てみましょう。すべての存在は架空のものであるため、誰も推測できません。

ある程度の本質はある。連絡を入れましょう。標準化された本文を持つ文字があり、そこからパーサーとハイドレーターが同じ連絡先を作成します。手紙が到着し、私たちはそれを読み、キーと値のペアに解析して連絡先を作成し、データベースに保存しました。

初歩的なことです。連絡先に氏名、年齢、連絡先電話番号のプロパティがあるとします。このデータは手紙で送信されます。また、企業は、エンティティのプロパティをレター本文のペアにマッピングするための新しいキーを迅速に追加できるサポートも求めています。誰かがテンプレートにタイプミスをした場合、またはリリース前に新しいフォーマットに適応して新しいパートナーからマッピングを緊急に起動する必要がある場合。その後、新しいマッピング相関を安価なデータフィックスとして追加できます。つまり、人生の一例です。

私たちはテストを実装し、作成します。動作します。

コードは提供しません。ソースは多数あり、記事の最後にあるリンクから GitHub で入手できます。あなたのケースに影響を与えるように、それらをロードし、認識できないほど拷問し、測定することができます。高速であると想定されるハイドレーターと、低速であると想定されるハイドレーターを区別する 2 つのテンプレート メソッドのコードのみを示します。

ロジックは次のとおりです。テンプレート メソッドは、基本的なパーサー ロジックによって生成されたペアを受け取ります。 LINQ レイヤーはパーサーおよびハイドレーターの基本ロジックであり、データベース コンテキストにリクエストを発行し、キーをパーサーからのペアと比較します (これらの関数には、比較用の LINQ を使用しないコードがあります)。次に、ペアはメインの水和メソッドに渡され、ペアの値がエンティティの対応するプロパティに設定されます。

「高速」 (ベンチマークでは接頭辞として「高速」):

 protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var setterMapItem in _proprtySettersMap)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == setterMapItem.Key);
                setterMapItem.Value(contact, correlation?.Value);
            }
            return contact;
        }

ご覧のとおり、セッター プロパティを持つ静的コレクションが使用されています。これは、セッター エンティティを呼び出すコンパイルされたラムダです。次のコードによって作成されます。

        static FastContactHydrator()
        {
            var type = typeof(Contact);
            foreach (var property in type.GetProperties())
            {
                _proprtySettersMap[property.Name] = GetSetterAction(property);
            }
        }

        private static Action<Contact, string> GetSetterAction(PropertyInfo property)
        {
            var setterInfo = property.GetSetMethod();
            var paramValueOriginal = Expression.Parameter(property.PropertyType, "value");
            var paramEntity = Expression.Parameter(typeof(Contact), "entity");
            var setterExp = Expression.Call(paramEntity, setterInfo, paramValueOriginal).Reduce();
            
            var lambda = (Expression<Action<Contact, string>>)Expression.Lambda(setterExp, paramEntity, paramValueOriginal);

            return lambda.Compile();
        }

一般的にそれは明らかです。プロパティを走査し、セッターを呼び出すプロパティのデリゲートを作成し、それらを保存します。その後、必要に応じて電話をかけます。

「遅い」 (ベンチマークでは接頭辞が「遅い」):

        protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var property in _properties)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == property.Name);
                if (correlation?.Value == null)
                    continue;

                property.SetValue(contact, correlation.Value);
            }
            return contact;
        }

ここでは、すぐにプロパティをバイパスし、SetValue を直接呼び出します。

明確にするため、および参考として、相関ペアの値をエンティティ フィールドに直接書き込む単純なメソッドを実装しました。プレフィックス – 手動。

それでは、BenchmarkDotNet を使用してパフォーマンスを調べてみましょう。そして突然... (ネタバレ - これは正しい結果ではありません。詳細は以下にあります)

ここで何が見えるでしょうか？ Fast プレフィックスを誇らしげに持つメソッドは、ほとんどすべてのパスで Slow プレフィックスを持つメソッドよりも遅いことがわかります。これは、作業の割り当てと速度の両方に当てはまります。一方、可能な限りこれを目的とした LINQ メソッドを使用した美しくエレガントなマッピングの実装は、逆に生産性を大幅に低下させます。その違いには秩序があります。パス数が変わっても傾向は変わりません。唯一の違いはスケールです。 LINQ では 4 ～ 200 倍遅くなり、ほぼ同じ規模でより多くのゴ​​ミが発生します。

UPDATED

私は自分の目を信じていませんでしたが、さらに重要なことに、同僚は私の目もコードも信じていませんでした - ドミトリー・チホノフ 0x1000000。私のソリューションを再確認した後、彼は、最初から最後まで、実装における多数の変更により私が見落としていたエラーを見事に発見し、指摘してくれました。 Moq セットアップで見つかったバグを修正した後、すべての結果が適切な位置に収まりました。再テストの結果によると、主な傾向は変わっていません。LINQ は依然としてリフレクションよりもパフォーマンスに影響を与えています。ただし、Expression コンパイルの作業が無駄に行われず、割り当てと実行時間の両方で結果が見えるのは素晴らしいことです。静的フィールドが初期化される最初の起動は、当然「高速」メソッドの方が遅くなりますが、その後は状況が変わります。

再テストの結果は次のとおりです。

結論: 企業でリフレクションを使用する場合、特にトリックに頼る必要はありません。LINQ は生産性をより多く消費します。ただし、最適化が必要な高負荷メソッドでは、イニシャライザとデリゲート コンパイラの形式でリフレクションを保存でき、これにより「高速」ロジックが提供されます。こうすることで、リフレクションの柔軟性とアプリケーションの速度の両方を維持できます。

ベンチマーク コードはここから入手できます。誰でも私の言葉を再確認できます。
ハブラ反射テスト

PS: テストのコードは IoC を使用し、ベンチマークでは明示的な構造を使用します。実際のところ、最終的な実装では、パフォーマンスに影響を及ぼし、結果にノイズが多くなる可能性のある要素をすべてカットしました。

PPS: ユーザーに感謝します ドミトリー・ティホノフ @0x1000000 最初の測定に影響を与えた、Moq 設定時の私の間違いを発見してくれました。読者の中で十分なカルマを持っている人がいたら、「いいね」をしてください。男は立ち止まり、男は本を読み、男は再確認して間違いを指摘した。これは尊敬と共感に値すると思います。

PPPS: スタイルとデザインの本質を理解した細心の読者に感謝します。私は統一性と利便性を重視しています。プレゼンテーションの外交的な部分には多くの要望が残されていますが、私は批判を考慮に入れました。飛び道具をお願いします。

出所： habr.com