第2回：init処理とprototype (3/3)

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

第２回：init処理とprototype
著者：株式会社電通国際情報サービス  比嘉康雄
         株式会社アークシステム  本間宏崇
         日本ヒューレット・パッカード株式会社   2006/6/8

prototype

DIコンテナには、先ほどのsingletonの他にもprototypeというインスタンスモードがあります。singletonとの違いは、コンテナから取得するたびに異なるインスタンスが返される点です。つまりコンポーネント取得時に毎回インスタンスを生成しているということです。

測定プログラム

Seasar2でのプログラムを掲載します。Springでも同様です。

設定ファイル（Seasar2）


		<components>

		   <component name="nullBean00000" class="xxx.NullBean00000" instance="prototype"/>

		   <component name="nullBean00001" class="xxx.NullBean00001" instance="prototype"/>

		   :

プログラム（Seasar2）


		DecimalFormat format = new DecimalFormat("00000");

		// 1度目の取得

		long start = System.currentTimeMillis();

		for (int i = 0; i < times; i++) {

		   Object component = container.getComponent("nullBean" + format.format(i));

		}

		long end = System.currentTimeMillis();

		// end - startを記録

		

		// 2度目の取得

		start = System.currentTimeMillis();

		for (int i = 0; i < times; i++) {

		   Object component = container.getComponent("nullBean" + format.format(i));

		}

		end = System.currentTimeMillis();

		// end - startを記録

結果

なかなか興味深い結果となりました。コンテナ生成（図3）はほぼ同じ速度ですが、1度目のコンポーネント取得（図4）では20〜30倍の差がついています（1,000個のコンポーネントで1.5秒）。また2回目のコンポーネント取得（図5）は3〜5倍Seasar2の方が速い結果となりました（1,000個のコンポーネントで130ミリ秒）。しかしそれほど大きい数値ではありません。

図3：prototype、コンテナ生成

図4：prototype、コンポーネント取得（1度目）

図5：prototype、コンポーネント取得（2度目）

※注2：
この測定では1,000個より2,000個の方が速いという不可解な結果がでてしまいました。1度目の取得では1,000個より2,000個の方が、時間がかかるという順当な結果なのですが（グラフは省いています）、2度目の取得はご覧の通りです。理由をお伝えできないことをお詫びいたします。

理由

まずコンテナ生成と1度目のコンポーネント取得について考えてみましょう。Springの結果は、第1回の図1、2と似ていることがわかります。ApplicationContextを使うことで、singletonコンポーネントの取得は速くなりましたが、prototypeコンポーネントの取得には影響がなさそうです。

この原因は次のように考えられます。

ApplicationContextではコンテナ生成時にsingletonコンポーネントのリフレクション情報キャッシュとコンポーネント生成が行われるが、prototypeコンポーネントは対象外であるため
prototypeコンポーネントは、1度目の取得時にリフレクション情報キャッシュとコンポーネント生成が行われるため

表3：prototypeコンポーネントによる差の原因

Springのリフレクション情報取得処理は遅いため（「第1回：どっちが速いSeasar2 VS Spring」の図3を参照）、prototypeコンポーネントでもコンテナ生成時に行って欲しいと思うのは筆者だけでしょうか。

次に2度目のコンポーネント取得の差についてですが、Springでは対象となるコンポーネントに加えてBeanWrapperImplクラスを毎回生成していることが、原因の1つと考えられます。

おわりに

次回はDIコンテナのまさにメインとなる機能であるDI処理のパフォーマンスを見ていきます。

また、ベンチマークプログラムを下記のSubversionリポジトリで公開しています。興味のある方はSubversionクライアントからチェックアウトしていただけましたらと思います。

https://www.seasar.org/svn/s2container/trunk/seasar-benchmark

前のページ 1 2 3

著者プロフィール
株式会社電通国際情報サービス比嘉康雄
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
第2回：init処理とprototype
	はじめに
	結果
	prototype

パフォーマンス徹底比較!! Seasar2 VS Spring
第1回	どっちが速いSeasar2 VS Spring
第2回	init処理とprototype
第3回	DI処理のパフォーマンス比較
第4回	AOP機能のパフォーマンス比較

タイプ

連載

特集

人気記事トップ10

新着記事

企画広告も役立つ情報バッチリ！ Sponsored