3

LLBLGen Proのパフォーマンス情報を探して、インターネットの高低を検索しました。見つかりませんでした。LLBLGenProがNhibernateと比較してどのように機能するかを知りたかっただけです。ありがとう

4

2 に答える 2

6

あなたの質問は、文脈なしでは基本的に答えられません。それに応じて私が尋ねる質問は、次のように始まります。

  • どのようなアプリケーションですか？データ中心？ビジネスロジック中心？
  • どのくらいのデータについて話しているのですか?
  • どのような種類のデータ操作について話しているのですか? ほとんど読む？ほとんど書き込み？

一般的に、LLBLGen は非常に優れたパフォーマンスを発揮します。私が働いている 10 以上のプロジェクト (いくつかのエンタープライズ規模のプロジェクトを含む) でそれを使用してきましたが、パフォーマンスに関して見られたいくつかの問題は常に、コードが何をしているのかを誤解した結果でした (学習曲線があります)。不十分に実装された物理モデル (インデックスの欠落など)。

2 つのフレームワークは、データ アクセスの問題へのアプローチが大きく異なります。LLBLGen の操作は、一般に、データのバックグラウンドが豊富な場合に非常に理解しやすい SQL に変換されます。NHibernate はセッションとキャッシュを使用して、可能な場合はデータをメモリに保持し、パフォーマンスを向上させます (免責事項: 私は NHibernate の専門家ではありません)。LLBLGen はこの種の概念をサポートしていません。代わりに、切断された状態で動作し、変更追跡情報をそのエンティティ オブジェクトに直接保存します。

要するに、フレームワークが採用するアプローチは大きく異なり、システムが何を行っているかを詳しく知らなければ、どちらがより優れたパフォーマンスを発揮するかを予測することは困難です。どちらのフレームワークも、適切に使用すれば、データ アクセス パフォーマンスがパフォーマンスの主要なボトルネックにならないシステムを設計するために使用できます。

于 2009-12-05T17:56:29.717 に答える
4

最初にLLBLGen@ORMBattle.NETをテストしましたが、具体化に関してはNHよりも約2倍高速でした。LINQクエリのコンパイル時間はかなり良好でした（〜4000クエリ/秒）が、CUD操作はNHよりも著しく低速でした（LLBLGenにはCUDバッチ処理はありません）。

同じセッションで大量のオブジェクトを処理する場合、両方のフレームワークは比較的低速である必要があります。

  • NHは、その具体化パイプラインのために比較的遅いです。理由はよくわかりませんが、たとえばダーティチェックを実装するには、NHはマテリアライズされたオブジェクトのクローンをどこかに保存する必要があります。少なくとも2倍のRAM〜=少なくとも2倍遅い。
  • LLBLGenは比較的「太い」エンティティを使用します-それらは辞書にフィールドを格納しているようです。明らかに、RAMの消費はそれに影響を与える重要な要因の1つであるため、これはパフォーマンスの観点からは良くありません。

もう少し詳細な説明については、このFAQの質問とテストスイートの概要を参照してください。

つまり、LLBLGen Proは、読み取りではNHより高速である必要がありますが、書き込みでは低速である必要があります。

于 2009-12-04T18:03:54.417 に答える