JDBC、S2JDBC、S2Dao、JPA(Hibernate)、Domaのパフォーマンス比較 その2

前回につづいてパフォーマンス比較をしてみました。ただし、前回と測定方法変えてます。最適化された状態で計測するため1プロセス内で同じ処理を3回実行して最後の値を取る、ということをそれぞれのテストケースで3回実行して真ん中の値を使っています。
コードや使用しているライブラリはリポジトリにあります。
https://www.seasar.org/svn/sandbox/doma/trunk/or-mapper-benchmark/

SQLファイルに記述されたSELECT文を使って10000件検索
22,200,648 (nanoTime) : DomaSqlFileSelectDtoTest
39,252,773 (nanoTime) : S2DaoSqlFileSelectDtoTest
68,378,980 (nanoTime) : S2JdbcSqlFileSelectDtoTest
自動的に組み立てられたINSERT文で10000件を1件ずつ追加(IDの採番はシーケンスで)
241,928,187 (nanoTime) : DomaInsertSequenceTest
574,420,603 (nanoTime) : JdbcInsertSequenceTest
156,897,072 (nanoTime) : JpaInsertSequenceTest
233,943,081 (nanoTime) : S2DaoInsertSequenceTest
129,143,877 (nanoTime) : S2JdbcInsertSequenceTest
自動的に組み立てられたUPDATE文で10000件を1件ずつ更新
570,835,371 (nanoTime) : DomaUpdateTest
273,834,149 (nanoTime) : JdbcUpdateTest
594,098,134 (nanoTime) : JpaUpdateTest
534,463,909 (nanoTime) : S2DaoUpdateTest
461,464,713 (nanoTime) : S2JdbcUpdateTest
自動的に組み立てられたDELETE文で10000件を1件ずつ削除
234,067,733 (nanoTime) : DomaDeleteTest
105,918,145 (nanoTime) : JdbcDeleteTest
718,393,388 (nanoTime) : JpaDeleteTest
251,050,933 (nanoTime) : S2DaoDeleteTest
170,038,767 (nanoTime) : S2JdbcDeleteTest

前回からDomaメタデータの持ち方を効率的になるように変更しているため検索が一番速くなりました。更新系は相対的には遅いほう。ただ、どちらもあまり気になる差ではないです。
ここでいいたいのはDomaのパフォーマンスが他のO/Rマッパーに比べてすぐれているとかそういうことではなく、相対的に問題ないということです。

差があまりないとなると、O/Rマッパーの選定で重要になるのはパフォーマンスではないといえると思います(あんまり遅いのは問題外ですが)。開発のしやすさ、メンテナンスのしやすさ、管理のしやすさ、チューニングのしやすさ、学習コスト、アプリケーションへの適合度などのほうが重要でしょうね。Domaはそういうとこら辺をアピールしたいなと思っています。

追記 01/06 21:01

INSERTの比較で素のJDBCが遅いわけですが、理由はコメントに書いたとおりです。比較しているO/Rマッパーは、どれもパフォーマンスを向上させるためにシーケンスで採番する場合にシーケンスへのアクセスを減らす仕組みをもっています。
あと、UPDATEやDELETEで比較的遅いJPAがINSERTでは結構速いのですが、これはHibernateがデフォルトでバッチINSERTを使うようになっているからです。S2DaoS2JDBCDomaはバッチINSERTの機能を持っていますが、明示的に使わない限りバッチINSERTになりません。(Hibernateは暗黙的にバッチINSERTします)