S2Daoのソースを色々見ていたところ、

AbstractBeanMetaDataResultSetHandler#createRow()において、
以下の箇所が、Mappingとは無関係のPropertyのときも評価されており、
Entityの作り方次第で、同じSQLでも大量件数取得時(100件くらいでも)にSpeedに差が出ます。

＊自テーブルのMappingの話に限定しています。

} else if (!pt.isPersistent()) {
    for (Iterator iter = columnNames.iterator(); iter.hasNext();) {
        String columnName = (String) iter.next();
        String columnName2 = StringUtil
                .replace(columnName, "_", "");
        if (columnName2.equalsIgnoreCase(pt.getColumnName())) {
            ValueType valueType = pt.getValueType();
            Object value = valueType.getValue(rs, columnName);
            PropertyDesc pd = pt.getPropertyDesc();
            pd.setValue(row, value);
            break;
        }
    }
}

Mappingとは無関係のPropertyとは、
A. Setterの無いGetter
B. 子Tableの持つなどMappingとは別のTiming設定するjava.util.ListのPropertyなど

「A」は明らかです（Setできないし）。
「B」は「じゃあ、Mapはどうなんだ！？」とか線引きが難しいです。

そこで以下の修正案です。

1. 上記の処理の中でpt.getPropertyDesc().isWritable()でないものはすぐにcontinueする。

→ 「A」のみ対応

2. FastPropertyTypeFactoryとPropertyTypeFactoryImplにおいてpt.getPropertyDesc().isWritable()でないものは対象外とする。

(BeanMetaDataの属性として保持しないということ)
→ 「A」のみ対応
※RelationのMapping時にも有効になって一石二鳥。
※BeanMetaDataでReadOnlyのPropertyを保持しないでOKかどうかちょっとパッとわかりませんでした。

3. 上記の処理において、１ループ目でMapping対象となる「pt」の別途Listに詰めて２ループ目以降は、それを使う。

→ 「A」も「B」も対応
※createRow()の引数が一つ増えるので、少し影響範囲大きい。

4. 「2」 and 「3」の対応をする。

→ 「2」を対応するにしても「3」 をやるメリットはある。逆もまたしかり。

5. 何もしない

→ 実際に手動でEntityを作っていればあまり、そういったPropertyを作らないかもしれない。
DBFluteだと、Setterの無いGetterをEntityに作ることがあるので影響があるのだが、
それはDBFluteでどうにか対応すればよい。
(拡張のために上記の処理部分を別クラスで差し替え可能にするくらいはしたい....)

現在S2Daoの利用者はかなり多いため、慎重に修正方針を決めたいと考えます。
皆様、どう思われますでしょうか？ご意見下さい。