 |
|
|
| 前のページ 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 次のページ
|
|
|
|
|
|
|
|
|
著者プロフィール
株式会社アークシステム 本間 宏崇
プログラマ。2004年より(株)アークシステムに所属。最近の興味はペアプログラミング・テスト駆動開発・プロジェクト自動化など。現在はWebアプリケーションフレームワーク「Teeda
（http://teeda.seasar.org/ja/）」の開発に携わっている。
|
|
|
|
|
著者プロフィール
日本ヒューレット・パッカード株式会社
今回、Seasar2とSpringのパフォーマンスの検証を行う際の環境を提供しています。
|
|
|
|
|
|
