[
https://issues.apache.org/jira/browse/FELIX-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357656#comment-14357656
]
Guillaume Nodet commented on FELIX-4656:
----------------------------------------
I've tried to replace the CopyOnWriteList with the standard
CopyOnWriteArrayList and hit a problem because the iterator() on this list does
not support the remove() method. This method is used in
Candidates#checkSubstitutes() for example.
Another maybe small issue is that the purpose is to be as minimal in term of
memory. The CopyOnWriteArrayList cpu overhead may be small, but for each list,
it will consume some more memory (the size of an empty CopyOnWriteArrayList is
104 bytes vs 40 for the CopyOnWriteList). This 64 bytes comes from the lock,
which is an object, holding another object, itself containing 2 null objects
and an int and a Thread pointer.
I've made some rough performance measurements, running my big resolution test
10 times. The best run was 30535 ms with the CopyOnWriteArrayList and 27784 ms
with the current classes. That's a 9.9% increase. We also need to include the
memory cost which I estimate to more than 10 Mb in the above test (3500
candidates * 50 permutations in memory * 64 bytes, only counting the candidates
map, so not the path and the dependent map).
The performance cost may actually only come from cloning the lock several
thousand times, but in that case, it becomes non negligible I think.
> 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
>
>
> 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)
