[
https://issues.apache.org/jira/browse/FELIX-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5619:
---------------------------------
Fix Version/s: (was: org.apache.felix.dependencymanager-r10)
org.apache.felix.dependencymanager-r11
> MultiProperyFilterIndex memory consumption
> ------------------------------------------
>
> Key: FELIX-5619
> URL: https://issues.apache.org/jira/browse/FELIX-5619
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
> Affects Versions: org.apache.felix.dependencymanager-r9
> Reporter: Jeroen Daanen
> Assignee: Pierre De Rop
> Fix For: org.apache.felix.dependencymanager-r11
>
> Attachments: Filter.java, MultiPropertyFilterIndex.java,
> MultiPropertyFilterIndexPerformanceTest.java,
> MultiPropertyFilterIndexReferencedTest.java, MultiPropertyKey.java,
> MultiPropertyKeyTest.java, TestReference.java
>
>
> In our product using the dependency manager and having configured several
> filter index settings, the memory consumption of the MultiPropertyFilterIndex
> is relatively high because it contains a map of string keys to service
> reference, where the keys are concatenated strings based on the service
> properties. These strings are all newly created objects resulting in
> inefficient memory usage.
> In the attachment you find a version of the index which uses less memory
> because it no longer stores appended strings in new string objects, but
> stores the original strings in string arrays. This way it can benefit for
> instance from the garbage collector deduplicating strings.
> Also attached are some unit tests to ensure the behavior did not change (note
> that we could not find any existing unit tests on the
> MultiPropertyFilterIndex).
> If a large project is configured in our product we could have around 41500
> services total. The configured MultiproperyFilterIndexes then contain more
> then 500000 keys.
> When executing the attached unit test
> 'MultiPropertyFilterIndexPerformanceTest' for 500000 service references we
> found the memory consumption is reduced by 44%:
> Existing implemenation:
> fastest write time: 3.433 milliseconds
> fastest read time: 1.577 milliseconds
> memory consumption: 1374 MB
> New implementation:
> fastest write time: 2.329 milliseconds
> fastest read time: 1.997 milliseconds
> memory consumption: 771 MB
> Would it be either possible to replace the existing implementation or make it
> possible to supply a custom implementation of a filter index to the
> dependency manager?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
