[
https://issues.apache.org/jira/browse/FELIX-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356689#comment-14356689
]
Guillaume Nodet commented on FELIX-4656:
----------------------------------------
Basically, the path structure is the difference between the original candidate
map and the current one, i.e. it contains capabilities that have been excluded
because they could not be resolved. It is supposed to identify a Candidates
object. As you can see, the getPath() method returns Object, as the resolver
only needs to compare those without knowing the data structure.
My assumption is that if the map of possible capabilities is the same, the
resolution should lead to the same result. If the set of possibilities
matching capabilities is the same, the difference between the original set and
the set of capabilities (hence the path) is the same too. So by recording the
already explored Candidates, we avoid the fact that the resolver performs the
same computation on equivalent Candidates object.
With the resolution test I added, the resolver resolves 2623 Candidates and
ignore 4832 ones. The resolution takes roughly 34s on my laptop, while the
same resolution with the current trunk never finishes.
> Improve memory usage of the resolver
> ------------------------------------
>
> Key: FELIX-4656
> URL: https://issues.apache.org/jira/browse/FELIX-4656
> Project: Felix
> Issue Type: Improvement
> Components: Resolver
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
> Fix For: resolver-1.2.0
>
>
> During big resolutions (> 100 bundles), the memory consumption can become
> very huge, mostly by keeping a lot of copies of the Candidates object.
> I want to lower the memory requirements of the resolver without touching the
> algorithm at all (which would be a different improvement).
> This can be done by using :
> * lower memory intensive collections
> * do smart copies of those collections (where they would only actually copy
> the data when modify)
> The second item is slightly more difficult to achieve, as the maps in the
> Candidate objects contains Set and List, which would mean that those must be
> copied too. So it could actually be complementary, if achievable.
> For the first one, the HashMap and HashSet are very memory intensive. I'll
> introduce two new collections which will lower the requirements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
