AssistedInjection FactoryProvider.newFactory performance - slow

[cpea]

When I use the AssistedInject to generate a factory class
automatically, object creation takes a significantly longer time than
hand-coding the factory. My test involves creating 10,000 objects in a
loop. With the FactoryProvider.newFactory in my binding, it takes 7ms
to run the test. If I replace the binding with my own factory class
(which is a singleton), the test runs in 0.2ms.

Has anyone else run into this? Any ideas why it's so much slower? I'm
not happy about having to hand-code all the factories.

Thanks.

[cpea]

Sorry, I meant 7 seconds (not ms) for the auto generated factory, and
0.2 seconds for the hand-coded one.

[Fred Faber]

This is a known issue due to the way in which FactoryProvider2 operates.  For the time being, if you're seeing unacceptable performance, I suggest using the @AssistedInject annotation on your implementation classes versus the @Inject annotation.  There is a solution on the table to adjust the code, which will happen within the next month or so one way or the other.

I am interested in your benchmark.  Could you please describe how you ran it?

thanks
-Fred

On Wed, Mar 17, 2010 at 8:02 PM, cpea <cpri...@currenex.com> wrote:

Sorry, I meant 7 seconds (not ms) for the auto generated factory, and
0.2 seconds for the hand-coded one.

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To post to this group, send email to google...@googlegroups.com.
To unsubscribe from this group, send email to google-guice...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.

[cpea]

Hi Fred,

Thanks for the reply, I will try switching to @AssistedInject and look
forward to getting the fix in the future.

To test this I created a simple junit test that loops 10k times and on
each iteration uses Guice (using assisted injection) to create an
object. At the end of the test it prints out the time to run. I was
then able to reconfigure my Guice module from the autogenerated
factory to use a hand-coded factory and re-run the test to see the
difference.

Cheers!

[Kartik Kumar]

Not to belabor the obvious but I think there is an issue # 435 (to lazy to look up the link) on AssistedInject and lock contention.

--

[glenviewjeff]

Is there a packaged jar version of AssistedInject.jar that's based on the 2.0 branch that i can get that fixes this?  I can't yet upgrade to Guice 3.0 since Roboguice doesn't yet support 3.0. 

Why doesn't Guice package up and issue minor releases?

[glenviewjeff]

I'm using Guice 3.0, and the AssistedInjection FactoryModuleBuilder still appears to be unusably slow.  My app is taking about 15-20 seconds to start up, and about 30% of that time is spent creating about 20 factories.

[Sam Berlin]

Creation of the factories themselves aren't particularly optimized, calling factory.create(..) to create your assisted objects is what's optimized.  Creation of factories should only happen once (at startup), so the cost isn't as crucial.  If you have suggestions for optimizing the code, though, please file a bug with a patch!

 sam

--
You received this message because you are subscribed to the Google Groups "google-guice" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-guice/-/1QMiWgIdM3QJ.

[glenviewjeff]

Sam, while I don't think I'm quite yet qualified to patch the library, I do have a suggestion and pointer.  The slow performance is because Android is terribly slow at annotation reflection.  OrmLite, an ORM that supports Android nicely, improved things using a technique described in this Stack Overflow post:

"An interesting reflection performance improvement was given to me. We are now using reflection to peek inside the AnnotationFactory class to read the list of fields directly. This makes the reflection class 20 times faster for us since it bypasses the invoke which is using the method.equals() call. It is not a generic solution but here's the Java code from ORMLite SVN repository."