TOPシステム開発> prototypeコンポーネント(明示的にDIする場合)
パフォーマンス徹底比較!! Seasar2 VS Spring
パフォーマンス徹底比較!! Seasar2 VS Spring

第3回:DI処理のパフォーマンス比較
著者:株式会社電通国際情報サービス  比嘉 康雄
         株式会社アークシステム  本間 宏崇
         日本ヒューレット・パッカード株式会社   2006/6/15
前のページ  1  2   3  4  次のページ
prototypeコンポーネント(明示的にDIする場合)

   prototypeコンポーネントならコンテナから取得するたびにDIが行われるので、DI処理だけでどれくらい時間がかかるのかがわかります。結果は以下の通りです。
コンテナ生成
図4:コンテナ生成

DIしたコンポーネントを取得(1度目、明示的にDIする場合)
図5:DIしたコンポーネントを取得(1度目、明示的にDIする場合)

DIしたコンポーネントを取得(2度目、明示的にDIする場合)
図6:DIしたコンポーネントを取得(2度目、明示的にDIする場合)

   図6の2度目のコンポーネント取得が、明示的に指定した場合でのDI処理の速度差となります。今回の測定では4倍の差が出ました(1,000回のDIで250ミリ秒)。

   またsingletonの時に比べて、Springはコンテナ生成が速く1度目のコンポーネント取得が遅くなっていますが、これはprototypeの項で取り上げた通り、リフレクション情報のキャッシュを1度目のコンポーネント取得時に行っているためです。第1回の図3を見るとコンポーネント2,000個で3秒かかっているので、計算もあいます。

   このDI処理での速度差の原因には、リフレクションクラスの性能差が考えられます。DI処理の時にはリフレクションでプロパティへアクセスしているためです。そこで、第1回でも登場したBeanDescImplとBeanWrapperImplを直接呼び出してプロパティアクセス速度を測定してみました(図7)。

リフレクションでのプロパティアクセス
図7:リフレクションでのプロパティアクセス

   図7の結果を見ると1,000回のアクセスで、4倍(100ミリ秒)ほどSeasar2の方が速い結果となりました。やはり、リフレクションの性能差はDI処理の速度差の一因といえそうです。

前のページ  1  2   3  4  次のページ


株式会社電通国際情報サービス  比嘉 康雄
著者プロフィール
株式会社電通国際情報サービス  比嘉 康雄
1992年、電通国際情報サービス入社。1996年にOracleに触れたことでソフトウェアの魅力に開眼。その後、日本産オープンソース「Seasar」の開発を中心になって行い、2004年5月に「Seasar2」をリリース。
http://www.isid.co.jp/
http://d.hatena.ne.jp/higayasuo/

株式会社アークシステム  本間 宏崇
著者プロフィール
株式会社アークシステム  本間 宏崇
プログラマ。2004年より(株)アークシステムに所属。最近の興味はペアプログラミング・テスト駆動開発・プロジェクト自動化など。現在はWebアプリケーションフレームワーク「Teeda
http://teeda.seasar.org/ja/)」の開発に携わっている。

日本ヒューレット・パッカード株式会社
著者プロフィール
日本ヒューレット・パッカード株式会社
今回、Seasar2とSpringのパフォーマンスの検証を行う際の環境を提供しています。

INDEX
第3回:DI処理のパフォーマンス比較
  はじめに
prototypeコンポーネント(明示的にDIする場合)
  測定プログラム(自動でDIする場合)
  prototypeコンポーネント(自動でDIする場合)