Community
Participate
Working Groups
While profiling bug 179581 perspective switch test noticed there is a performance drop in EclipseStorageHook#hasPackageInfo(*) 320: 118 times, 343ms 330: 157 times, 11625 ms Invocations for 3.2.0: 16914 String#startsWith(*) 2937 BufferedReader#readLine(*) Invocations for 3.3.0: 951402 String#startsWith(*) 158723 BufferedReader#readLine(*) The number of calls are increasing by a couple order magnitude. The time's here are profiled times, the relative time is important. PW
The static method EclipseStorageHook#hasPackageInfo(URL url) is only called during a clean initialization. It gets called once each time a bundle is installed. The jump in the calls to String#startsWith(*) and BufferedReader#readLine(*) are because the manifest files are much larger now that we have signed bundles. We only do this on first install so that we don't have to do it over and over from a cached configuration. When are you seeing this code get run? On initial startup from a clean configuration or after the application has been started and you are performing some action?
(In reply to comment #1) > The static method EclipseStorageHook#hasPackageInfo(URL url) is only called > during a clean initialization. It gets called once each time a bundle is > installed. The jump in the calls to String#startsWith(*) and > BufferedReader#readLine(*) are because the manifest files are much larger now > that we have signed bundles. > > We only do this on first install so that we don't have to do it over and over > from a cached configuration. When are you seeing this code get run? Yes, as discussed I'm running from a junit plugin launch config. With the large manifests it might be there's nothing you can do about this. PW
Unfortunately I don't see anything we can do here. We cannot stop parsing the manifest at the first blank line like we do in other areas to improve performance when parsing signed manifests. This is because package info can be in any section of the manifest (not just the first section like OSGi manifest headers). I do not think this is a big issue because this occurs during initial installation only.
Ultimately there may be some sort of marker we can put in manifests that would allow us to stop parsing. assuming that the signing utility always appends its info, we could append a line just before signing. Then when parsing, if we see this marker we can stop as we know that only signing info is after that point. I'm going to reopen this bug to track this idea.
Closing old bug as wontfix.
