Improve MVC 3, 4 application View DI performance - #91
Conversation
Ignore MVC view service injection check to improve MVC 3, 4 view object creation performance.
|
See #90 (comment); suggesting we centralize discussion of this PR there since so similar in scope/intent. |
Improve MVC 3, 4 application View DI performance
|
One thing that I just remembered is that we probably should also cache the type resolution result. It's quite costly to find types that implement/extend the type. After all we use the first result. So caching the result object name in container would give good performance boost. Unlikely that implementation would be swapped during runtime, but caching could be behind option that defaults to true. I profiled this once and GetObjectsOfType was eating the cycles. |
|
That makes some sense, but are you suggesting caching this in the container itself (generally) or just in the specific MVC use-case of the DependencyResolver? |
|
I was thinking the specific resolver. Would be well contained and MVC is less dynamic in nature (usually no child containers etc). And MVC rules are quite clear, single or nothing expected as resolution result. |
|
Reasonable; I''l try to make that change during my flight tomorrow and then we should be (more or less) ready to go with the release. FWIW, I'm thinking that so much time has elapsed since the RC1 release (and we've since added diff. Common.Logging, new NHibernate, etc. versions) that RC1 isn't really any longer functional as a release candidate. I'd like to get an RC2 release out there for about 2 weeks before formerly going forward with the GA sometime approx. mid-FEB. |
|
Sounds very reasonable, +1. |
Ignore MVC view service injection check to improve MVC 3, 4 view object
creation performance.