[
https://issues.apache.org/jira/browse/ARIES-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712794#comment-14712794
]
Bas commented on ARIES-1357:
----------------------------
1) Yes this was the primary objective, does my explanation of how it should
improve performance hold up?
2) The original code was already doing that, I didn't dive into why the code
was doing that so I also don't know. I just tried to eliminate processing that
could be done once instead of many times. So I'm storing the result of the
verification. That it is a constituent in the header and I am re-using it. The
verified list should be thrown away when the manifest is updated. Getting the
capabilities of the constituents and holding that list might also be an option
(even better) but because of fragments attaching and other dynamic osgi
features I thought to leave that as-is.
3) I looked at how other osgi parts where handling their manifest processing
and looked at
(http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.framework/5.0.0/org/apache/felix/framework/BundleRevisionImpl.java#BundleRevisionImpl).
Others were also pre-calculating data from the manifest so I decided to lookup
which data was used a lot in the resolve process and to at least pre-calculate
this data to make the resolve process faster. With a lot of subsystem features
no performance improvement will be noticed. When we work with an osgi container
that holds 10 subsystems you probably don't notice any performance increases.
When the number gets higher (200) the smaller things get bigger and noticable.
I will add a jvisualvm dump that has 85 flows (170 subsystems) and does not
have the getCapabilities improvement. It is an older snapshot and I don't
really know the exact test case anymore but it does show how much time the
getCapabilities takes in relation to the entire install process.
> BasicSubsystem can be used by the subsystem install process a factor 6 times
> faster
> -----------------------------------------------------------------------------------
>
> Key: ARIES-1357
> URL: https://issues.apache.org/jira/browse/ARIES-1357
> Project: Aries
> Issue Type: Improvement
> Components: Subsystem
> Affects Versions: subsystem-core-1.2.0, subsystem-2.0.1
> Environment: linux windows java
> Reporter: Bas
> Assignee: John Ross
> Labels: patch, performance
> Fix For: subsystem-core-1.2.0, subsystem-2.0.1
>
> Attachments: patch-basicsubsystem.patch,
> subsystem-basicsubsystem-patch.txt
>
>
> The problem was poor performance while installing a subsystem on a container
> with 200+ subsystems installed.
> While doing performance analyses on the subsystem install process we noticed
> the BasicSubsystem is working a lot with its manifest instead of
> pre-calculating data that is used a lot.
> While using the pre-patch version of BasicSubsystem a subsystem install
> (while having 200+ running subsystems) could take more than a minute. While
> using the patched version where we pre-calculate highly used data when a new
> subsystem manifest or deployment manifest is set we could bring it down to 10
> seconds. We only pre-calculated the data that was highly used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
