StatusをResolveにするのを忘れていました。
Relsolveにします。

DTOも対応しました。
もともとDTOの方はそんなに遅くなかったですが、
統一性の観点から同じ構造にしました。
(1000件HIT検索で平均160msが平均140msくらいにはなったかな...)

Relationも対応しました。

Entityの作り方次第で変動するので正確ではないですが(かつローカル環境)、
S2Dao-1.0.46から比べて、単純な1000件HIT検索で平均400msが平均150msになりました。すごい。

補足ですが：

Map cache = null;
while(rs.next()) {
  if (cache == null) {
    cache = createCache(...);
  }
  Object row = createRow(..., cache);
  ...
}

と言う感じにしました。
検索結果が1件も存在しない場合には
Cacheを作成しないようにしています。

非常に良いと思います。
そこまで変えてしまっても良いかなとちょっと思いましたが、
ここまできたらやってしまいましょう。
（DBFlute側のテストもあることですし）

対応しました。
S2Daoのテスト/DBFluteのテスト両方グリーンです。
しかも、ちょっと正確に測ってないですが、1000件検索随分速くなった気がします。
(少なくとも10msは速くなってる)

Relationの方はもう少し複雑なのですが、多分いけると思います。
ちょっと検討してみます。

RowCreatorImplですが、
キャッシュを使う場合でもsetupPropertyメソッド以降で
条件分岐やループが行われていますが、
実はこのあたり一回だけ動けばいいように見えました。

PropertyTypeのキャッシュはSetじゃなくてkeyをカラム名にした
Mapにして、キャッシュの作成とrowの作成を完全に別処理にして
しまうのはどうでしょう。

イメージとしてはこんな感じを思い浮かべてみました。

 
Map cache = createCache(...); // 呼び出し先でsetupPropertyメソッド相当の処理
while(rs.next()) {
  Object row = createRow(..., cache);
  ...
}

RelationRowCreatorImplの方はちょっと確信ないですが、
同じような対応で効果があるように見えました。

Relationの方も全く同じ方法で対応しました。

1000件検索で、
Mappingに関係の無いPropertyを6個持つEntityが戻り値において 平均500ms → 平均200ms になりました。
Relationにも対応したことにより、素のEntityとのSpeedの差はほとんどなくなりました。
(差はあっても数ミリ秒。別の要因で簡単に覆る程度なので無いと考えて良いかと)

特にバッチでの検索などでかなり向上したのではないかと思います。
ご意見ありがとうございました。

こちらC#版でも全く同じですので対応を検討したいと思います。
(C#の方のJIRAへ同様の課題にしておきます)

Relationの方も同じやり方でできないか探ってみます。

「1」と「3」をローカルで実装してみました。
(「1」も他の影響が無いため＆１レコード目のPerformanceが良くなる)

S2Dao/DBFluteのUTは全て通りました。
問題なく値は取得できているようです。
また、DBFluteのPerformance測定のTestにおいても
ほとんど、差が無くなりました。
(Mappingとは無関係のPropertyが定義されていても速い)

他に何か意見がありましたら、お願いします。
(少し精査して特に問題なければこれでいきたいと思います)

> 「1」と「2」の場合ですが、PropertyDesc()#isWritable()はS2.4のメソッドなのでS2.3では
> PropertyDesc()#hasWriteMethod()を呼ぶようにする必要がありますね。

おっと、なるほど。気をつけなければならないですね。
ありがとうございます。

> 影響範囲を考えると「3」

なるほど、逆に「3」の方が限定的で安全というところですね。

あっ、上のコメントしたのは私（taedium）です。

影響範囲を考えると「3」が安全だと思います。
「1」と「2」の場合ですが、PropertyDesc()#isWritable()はS2.4のメソッドなのでS2.3では
PropertyDesc()#hasWriteMethod()を呼ぶようにする必要がありますね。

うおお、キレイになった！ありがとうございます！
JIRAの書き方ってのがあるんですね。。。

カラム名とプロパティ名のマッチングは、結果セットが1000行あっても1度だけ行えば良いのですから、ループの初回のみでマッチングをすれば良いのかなあと思います。
なので「3」ですかねぇ。

もとの投稿をJIRAっぽく整形してみました。

個人的には
(影響の大きさとか)色々考えてて、
現状では「2」と「5」ってのもアリかと思っています。
つまり、S2Daoとして「2」のみ対応。

「2」に関してですが、
AbstractPropertyTypeFactory#createDtoPropertyTypes()も
修正対象ですね。。。

「2」を試しにローカルで修正してもS2DaoのUTは全部通りますね。
DBFluteのUTも２つ除いて通りました。これだけでもかなり速くなりました。
(落ちた２つはpropertyTypeFactoryBuilderが無いって
怒られた...別問題ですね)