Done, thank you for the suggestion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=453256
On Tue, Nov 25, 2014 at 3:56 PM, Alex Blewitt <[email protected]> wrote: > It would be better to create a bug report at bugs.eclipse.org and attach > the files and description there. > > Alex > > Sent from my iPhat 6 > > On 25 Nov 2014, at 21:26, Colin Williams <[email protected]> > wrote: > > Hi everyone, > > This is a follow-up to my forum post [1], because I have more information > now and firmly believe this is a problem with Equinox, and not my code. I > have a simplified test case that duplicates the problem [2], and have > verified that Felix does not exhibit the same behavior. > > When firing up a new instance of a Declarative Services component, either > a regular component or a newInstance of a ComponentFactory, Equinox checks > for dependency cycles ([3] and [4], for regular components and component > factory instances, respectively). Unfortunately, it does this by walking > the entire list of components and factory instances to check for > dependencies, and then walking the entire dependency graph to check for > cycles (see [5] and [6]). After checking for cycles, it then walks the > entire list again [7] to check for components that may need to be disabled > based on the new dependency graph. > > Now, I'm not sure why the dependency cycle checking is necessary when > activating a new factory instance, since presumably it would have been > checked when the component was resolved or at least the first time an > instance of that factory was created. Even if it is necessary every time, > though, wouldn't it only be necessary to check the portion of the > dependency graph that is reachable from the new instance, rather than the > entire dependency graph of all enabled components? And then furthermore, > wouldn't it only be necessary to check the same list of potentially > affected components for ones that need to be disabled, rather than all of > them? > > As a result of this, Equinox exhibits O(n^2) runtime in activating new > components or creating new instances of factory components, based on the > number of components in the runtime and the complexity of the dependency > graph. In my test case [2], a fairly simple dependency graph (B->C->D), > which is then referenced by 3000 factory instances (A->B), takes minutes to > start because of this (see [9]). Adding this bundle to a Felix container > results in Felix starting the bundle and all 3000 factories instantly. > > I will say that I'm not particularly familiar with the Equinox internals, > but I have added timing information into a local copy of the DS project, > and can verify that findDependencyCycles and resolveEligible both take an > excessive amount of time, proportionate to the number of total components > in the system. I'm also not very familiar with the Felix internals, but I > can't see that Felix does any dependency cycle checking when creating a new > factory instance ([8]). > > I hope this was detailed enough to explain the problem I'm experiencing. > Can anyone verify that this is an issue, or explain why it needs to be > done? Or offer workaround suggestions to allow us to still use DS > ComponentFactories with more than a few hundred services/factories? > > Thanks, > --Colin > > [1] - https://www.eclipse.org/forums/index.php/t/868856/ > [2] - Attached > [3] - > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n476 > [4] - > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1042 > [5] - > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1073 > [6] - > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1140 > [7] - > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n511 > [8] - > https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/manager/ComponentFactoryImpl.java#L120 > [9] - http://pastebin.com/CNrHFE8C > [10] - http://pastebin.com/mb3AbP2S > > <com.i9technologies.equinoxtest_1.0.0.201411251422.jar> > > _______________________________________________ > equinox-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/equinox-dev >
_______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
