Odd .plus() performance.

[chrisjenx]

I feel I must be doing something really stupid as I am getting really odd performance issues from extending the graph for a second time.

I'm using Flow and have no more than 3 graphs at a time, Not too far off what Mortar does.

ApplicationScope > ActivityScope > FlowScope.

These are performance figures (I know not scientific, but slow enough to cause significant delay on a users device, HTC One M7 ART, I actually first noticed the 'lag' on Genymotion, which represents how slow this feels to the user).

• Extending AppGraph (For Activity) takes ~0-15ms Which is what I expect, especially from a cold start.
• Extending the ActivityGraph for the first FlowLayout takes in excess 212ms+ (Some cases 1100ms+)

This gets more interesting as if I navigate mFlow.goTo() / mFlow.goBack(), these subsequent FlowLayout ObjectGraph extensions take ~0-1ms. Which is more what I expect.

This feels like a locking issue? I haven't dug enough in the code base to see what happens during .plus().

Anything obvious I can try?

[chrisjenx]

Quick dive through the .plus method. I'm assuming that the first extension does full linking of the the graph and if its not done then syncs until its done.

So I guess is the Linker really that slow? If so surely I would see a really poor perf from Application to Activity? I probably add 10's of injectable classes at activity level.

I must be doing something complex which the Linker is struggling with?

[cgruber]

The linker is aggresively linking in the parent and does block until it's done. This is necessarily so in Dagger1 because there's no other way to figure out where an object will live (in the child graph or the parent graph) because of lazily linked graphs. If you depend on something in your activity, but it happens to not have been loaded in the parent, but shoudl be in the parent, then we would mistakenly initialize it in the graph if we didn't force pre-linking. (This is only relevant for @Singleton objects, and is largely an artifact of our using @Singleton to mean one-per-graph, not one-per-well-named-application-graph or some other special case).

Dagger 2 will have validation of custom scopes, so that if you have something in the parent graph it will only be memoized in the parent graph. So we can be more lean in terms of costs, only incurring the minimum costs needed for hte graph you use, rather than the sort of over-careful "link everything" we have to do now.

[chrisjenx]

@cgruber OK So I am correct in understanding that extending the graph will go ahead an initialize all the previous @Singletons in the parent graph(s)? Which would explain the high overhead as it's init stuff that I haven't yet called on in one hit?

So I guess I need to be more definitive with my Modules and try to reduce the library=true instances? Or init the Flow Modules into the activity graph...(which I don't really want to do)?

What's the timeframe for Dagger2?