felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Watson (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (FELIX-4656) Improve memory usage and speed of the resolver
Date Fri, 17 Apr 2015 20:27:58 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499908#comment-14499908
] 

Thomas Watson edited comment on FELIX-4656 at 4/17/15 8:27 PM:
---------------------------------------------------------------

Here is a suggested patch that simply does the cosmetic changes I suggested to change the
term path to delta.  If you agree could we get this patch released?  I think it should help
others to understand what is going on with the delta check.


was (Author: tjwatson):
Here is a suggested patch that simple does the cosmetic changes I suggested to change the
term path to delta.  If you agree could we get this patch released?  I think it should help
others to understand what is going on with the delta check.

> Improve memory usage and speed 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
>
>         Attachments: FELIX-4656.patch
>
>
> 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)

Mime
View raw message