On Thu, Dec 2, 2010 at 3:39 PM, David Blevins <[email protected]> wrote: > > Basically just attempting to strongly type that second hashmap. I'm a big > fan of incremental refactoring and this seemed like a nice baby-step that > didn't require us to break the existing WebBeansFinder API, yet still get > moving on going where we want to go.
Ok, here's where we are overall. Had mentioned in one of my commits we were near half the number of hash lookups. That was really just tracking that second hashmap lookup. Overall we still have a bit of work to do: r1041633 (the start) ----------------------------- 554 code uses Total of 265183 static synchronized accesses and 530365 hashed gets in 340 tests Average of 779 static synchronized accesses and 1559 hashed calls per test r1043210 (today) ----------------------------- 563 code uses Total of 263643 static synchronized accesses and 331125 hashed gets in 340 tests Average of 775 static synchronized accesses and 973 hashed calls per test The "static synchronized accesses" are calls to WebBeansFinder.getSingletonInstance. For the DefaultSingletonService these are statically synchronized, meaning only one thread per vm can make the call. This is probably where we are losing our performance as so many calls to BeanManager.getManager(), etc., all cause contention with every other thread in the vm. Something we wouldn't notice in a build environment, but definitely at production when there are many users threads executing all at once. What will affect that '775' number the most is consolidating calls to 'WebBeansContext.getInstance()' which is now the inlined version of all the previously existing 'getManager()' and 'getInstance()' calls. Here are our top 20 code usages of that method: 35 WebBeansUtil 27 BeansDeployer 13 WebBeansXMLConfigurator 9 TestContext 9 OpenWebBeansEjbInterceptor 7 AbstractLifeCycle 6 XMLDefinitionTest 6 InterceptorHandler 6 InjectionPointFactory 6 EjbBeanProxyHandler 6 BeanManagerImpl 5 WebBeansDecoratorConfig 5 WebBeansAnnotatedTypeUtil 5 StandaloneContainersImpl 5 LoggerSpecializationTest 4 XMLUtil 4 WebBeansInterceptorConfig 4 WebBeansInterceptor 4 ServiceLoader 4 ObserverMethodImpl Runtime usage is likely to show some different numbers as some of these classes are used less frequently or not at all after deployment. For example BeansDeployer is #2 in the usage list, but really wouldn't contribute anything to the runtime hits past deployment. Anyway, as you dig through the code, feel encouraged to eliminate duplicate WebBeansContext.getInstance() calls you encounter. Will be a long process trimming those down but the biggest impact on performance. Meanwhile I'm going to try and get some runtime usage stats to see what paths trigger the most hits so we can hopefully do some more quick refactors that lead to the most benefit. I.e. looking for more low hanging fruit we can easily pick. -David
