 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| prototypeコンポーネント（明示的にDIする場合） | ||||||||||||
|
prototypeコンポーネントならコンテナから取得するたびにDIが行われるので、DI処理だけでどれくらい時間がかかるのかがわかります。結果は以下の通りです。  図4：コンテナ生成  図5：DIしたコンポーネントを取得（1度目、明示的に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 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
