Re: [equinox-dev] Equinox DS Performance Problem

[Thomas Watson <tjwatson@xxxxxxxxxx>]

Thanks for opening the bug.

For a while now I have been contemplating
replacing the Equinox DS implementation with the Felix SCR/DS implementation
for use in Equinox/Eclipse.  There is no longer any active committers
working on the Equinox SCR/DS implementation.  I work closely with
one of the lead committers of the Felix SCR/DS implementations (who happens
to work for the same company as me).  For that reason I don't have
resources to spend on maintaining the Equinox SCR/DS implementation.  Nobody
else has step forward to take over the implementation of Equinox DS.

For the Mars release I plan on moving
the Felix implementation for Equinox/Eclipse.  So this is a last request
to the community.  If you have interest, skills and time to contribute
to the Equinox DS implementation let us know, otherwise I am moving forward
with using the Felix SCR/DS implementation for Mars.

Tom





From:      
 Colin Williams <colinw@xxxxxxxxxxxxxxxxxx>
To:      
 Equinox development
mailing list <equinox-dev@xxxxxxxxxxx>
Date:      
 11/25/2014 06:46 PM
Subject:    
   Re: [equinox-dev]
Equinox DS Performance Problem
Sent by:    
   equinox-dev-bounces@xxxxxxxxxxx

---

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 <alex.blewitt@xxxxxxxxx>
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 <colinw@xxxxxxxxxxxxxxxxxx>
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
equinox-dev@xxxxxxxxxxx
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
equinox-dev@xxxxxxxxxxx
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
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev