> (DBFLUTE-343){Java/C#}: > 検索結果マッピング時のEntityの生成をリフレクションレスに もともとDBFluteはEntityの「セッタ呼び出し」はリフレクションレス でしたが、Entityの生成(new Entity)もリフレクションレスにってのが この項目です。その結果がこちらです。 http://d.hatena.ne.jp/koyak/20081011/1223699743 詳細な検証、本当にありがとうございます。感謝感謝です。 検証はC#版ですが、Java版でも基本的には同じです。 DBFluteは徹底したパフォーマンスを追求しています。 その結果があらわれたようですね。 この記事には載っていませんが、個人的に聞いてみたところ、 セッタやEntity生成をリフレクション方式に戻すと２秒から３秒 遅くなるようです。（記事中の２００１３件検索にておいて） どうやらリフレクションレスはかなり効果があるようです。 リフレクション以外にも細かいところでチューニングを行っています。 それによって前バージョンよりも大幅に速くなっています。 具体的には： 実は、S2Daoにおいて、RelKeyがたくさん付いたEntityでそのRelationを 取得しないSQLで検索した際でも、Relationの値を取得しはしないものの、 最低限のRelation処理が走るためちょっと遅くなるということに気付きました。 これはS2Dao的には仕方のない処理ではあります。 しかし、DBFluteではその処理の前に「setupSelectしたRelationか否か」 を判断することが可能なため、チューニングすることが可能でした。 CBでsetupSelectされてないRelationはその処理が走らないように 調整を致しました。結果、今回のEntity生成のリフレクションレスよりも より大きいチューニングとなりました。 (DBFlute専用のマッピング処理クラスを作ってしまいました) DBFlute特有のこれらのチューニングは、 画面リクエスト上の２０件や５０件程度の検索ではほとんど差は ありませんが、ワンリクエストでSQLがたくさん発行されるとか、 取得カラムの数が膨大だとか、バッチ処理での検索とかにおいて 絶大な効果を発揮します。 そして、記事でもありますが、DBFluteの検索において最速は 「外だしSQL + カーソル検索」です。 DBFluteのカーソル検索はこれまた特徴的で、 「Entityへマッピングされた状態をコールバックで捕まえる」ではなく、 「Entityへのマッピングをせず、タイプセーフなResultSetのラッパ」で コールバック処理を行います。よって、最速であり、かつ、安全です。 http://dbflute.sandbox.seasar.org/contents/outside-sql/cursor.html
