felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5619) MultiProperyFilterIndex memory consumption
Date Thu, 11 May 2017 06:31:04 GMT

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

Pierre De Rop commented on FELIX-5619:
--------------------------------------

Jeroen,

The MultiPropertyFilterIndexPerformanceTest seems to be very time consuming, I guess it is
expected because this test is a performance benchmark test. But don't you mind if I decrease
the MultiPropertyFilterIndexPerformanceTest.testSize to a lower value like 50000 instead of
500000: this would make the test faster ? 

thanks 

> 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
>         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.3.15#6346)

Mime
View raw message