[ThinkIT] 第3回：DI処理のパフォーマンス比較 (3/4)

TOP＞システム開発＞測定プログラム（自動でDIする場合）

パフォーマンス徹底比較!! Seasar2 VS Spring

第３回：DI処理のパフォーマンス比較
著者：株式会社電通国際情報サービス  比嘉康雄
         株式会社アークシステム  本間宏崇
         日本ヒューレット・パッカード株式会社   2006/6/15

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

測定プログラム（自動でDIする場合）

次は自動DIについて見てみましょう。自動DIにはいくつかの種類がありますが、ここでは型によるDIを測定します。コンポーネントは「明示的にDIする場合」と同じものを使用します。Seasar2での設定ファイルは以下のようになります。

設定ファイル（Seasar2）


		<components>

		   <component name="component00000A" class="xxx.Bean00000AImpl" />

		   <component name="component00000B" class="xxx.Bean00000BImpl" />

		

		   <component name="component00001A" class="xxx.Bean00001AImpl" />

		   <component name="component00001B" class="xxx.Bean00001BImpl" />

		   :

明示的なDIの際には設定されたproperty要素が、省かれています。省いた箇所に相当する情報を、DIコンテナはコンポーネントのリフレクション情報から取得するわけです。

結果（自動でDIする場合）

コンポーネント取得速度は同程度ですが、コンテナ生成はSeasar2の方が3倍程速い（差は5秒と大きめ）結果となりました。また、明示的にDIしたときと比べると、Springのコンテナ生成速度が3秒ほど遅くなっていることがわかります。

図8：コンテナ生成（自動でDIする場合）

図9：コンポーネント取得（自動でDIする場合）

理由（自動でDIする場合）

   自動DIにしたことでSeasar2は速度にあまり変わりがありませんが、Springはコンテナ生成が極端に遅くなっています。その理由はDI対象を探すロジックにあります。

   SpringはDIのたびにコンテナへ登録されているすべてのコンポーネントへアクセスします。今回はコンテナへ2,000個登録されていて1,000回DI処理をしているので、「2,000個 × 1,000回」コンポーネント定義へアクセスしていることになります。

   それに対してSeasar2は、コンテナへコンポーネントを登録する際にクラスの型をキーとするハッシュテーブルへ登録しているため、DI処理の際に1回のアクセスで済んでいます。つまりリスト全件へアクセスするのか、ハッシュテーブルへキーでアクセスするのかの差なので、この結果にも納得できます。

前のページ 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する場合）