Although the Error object is still a large concern of mine, the Multibindings is much larger. I have managed to reduce our use of Multibindings considerably and this had a huge impact on performance. I got another 5-10% boost after removing as many as I could.
As for the Error objects, we are using a lot of @ImplementedBy annotations in our frameworks and libraries. We do this because it tends to provide simpler overriding of interfaces in applications that use the frameworks and libraries. I can use explicit bindings for everything and provide the overriding ability via a module where each binding is setup in a separate protected method. Then overrides would go in sub-classes. Not an ideal solution, but should work. If it would speed things up, it would be nice to be able to configure Guice to rip through the classpath on startup and convert all just-in-time bindings to explicit bindings. Not sure if this is possible, but could be a nice feature. Lastly, is the ConstructorContext also a symptom of just-in-time bindings as well? -bp On Aug 16, 2012, at 3:35 AM, Stuart McCulloch <[email protected]> wrote: > My gut feeling (given the large amount of transitory Errors instances) is the > application is doing a lot of lookups involving just-in-time bindings, maybe > also involving child injectors. > > When Guice attempts a just-in-time binding it keeps track of any errors - > when the uppermost binding fails the injector cleans up any intermediate > stray bindings and throws the aggregate Errors instance. > > If I can get some spare time this weekend I'll try a frequency analysis of > the Errors in that heap dump, this should indicate what bindings have the > most effect and whether child injectors are involved. > > On 15 Aug 2012, at 22:30, Brian Pontarelli wrote: > >> I thought I would share some information I've been collecting while >> profiling CleanSpeak. Just a quick run down on CleanSpeak to set the stage: >> >> Written entirely in Java >> Uses Prime MVC >> The test we setup was to our main WebService entry point >> This test simulates handling real-time chat inside games >> This is usually between 1,000-30,000 messages per second depending on the >> game >> CleanSpeak is currently able to handle 4,000-10,000 messages per second on a >> single server (we are working to get that higher though) >> Using a custom built load test system to simulate 10-100 clients hitting the >> WebService >> Using NetBeans profiler for timing metrics >> >> Based on the time profiling information we are getting from NetBeans, here >> are the top classes and the percentage of the processing time that they >> consume (full disclosure - I remove 3 of our classes from this list): >> >> com.google.inject.multibindings.MapBinder$RealMapBinder$2.get() >> 6.557378% >> com.google.inject.internal.InternalContext.getConstructionContext(Object) >> 3.3661668% >> com.google.inject.internal.Errors.withSource(Object) 3.2637234% >> freemarker.core.Environment.process() 2.9239252% >> com.google.inject.internal.InjectorImpl$4.get() 2.7241063% >> com.google.inject.internal.ConstructorInjector.construct(com.google.inject.internal.Errors, >> com.google.inject.internal.InternalContext, Class, boolean) 2.472883% >> org.primeframework.mvc.parameter.el.DefaultExpressionEvaluator.getValue(String, >> Object) 2.457187% >> org.primeframework.mvc.parameter.el.ExpressionException.<init>(String) >> 2.3623912% >> com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(Object[]) >> 2.3241668% >> org.primeframework.mvc.workflow.RequestBodyWorkflow.perform(org.primeframework.mvc.workflow.WorkflowChain) >> 2.286451% >> org.primeframework.mvc.servlet.ServletObjectsHolder.getServletRequest() >> 2.0882587% >> org.primeframework.mvc.parameter.el.MemberAccessor.getAnnotation(Class) >> 2.08238%3077 >> >> I left off everything below 2% use. The interesting things I've found here >> are that Multibindings appears to be quite expensive. I'm going to try and >> remove that use to see if I can get back that 6%. I also found that Error >> object that I wrote about in a previous post near the top at 3.26%. This >> seems to be quite expensive for an Error object, specifically when Guice >> errors are almost always found and fixed at test time and not in production. >> >> Has anyone else seen these types of performance results and have good >> insight into helping reduce them? >> >> -bp >> >> -- >> You received this message because you are subscribed to the Google Groups >> "google-guice" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-guice?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
