Community
Participate
Working Groups
I am running YourKit on the core headless startup performance test. About 11% of the total test time is inside ConfigApplier.installBundles when it invoktes Bundle.getHeaders(). This results in expensive lookup of localized manifest data. Tom suggested some optimizations: 1) Use getHeaders("") to prevent localization. They header we care about here isn't localized. 2) Perhaps the FRAGMENT_HOST header could be cached by the framework 3) Should this code even be running at all on second startup?
Created attachment 131280 [details] Profiler trace from fourth invocation of headless startup test
(In reply to comment #0) > I am running YourKit on the core headless startup performance test. About 11% > of the total test time is inside ConfigApplier.installBundles when it invoktes > Bundle.getHeaders(). This results in expensive lookup of localized manifest > data. Tom suggested some optimizations: > > 1) Use getHeaders("") to prevent localization. They header we care about here > isn't localized. > Should probably use PackageAdmin.getBundleType for the fastest way to find out if a bundle is a fragment. > 2) Perhaps the FRAGMENT_HOST header could be cached by the framework > > 3) Should this code even be running at all on second startup? > I know update configurator used to figure out if it needed to do some extra work. Not sure what all the issues are with doing that in simple configurator.
Thanks Tom. Trying this out in a test but should commit it to HEAD shortly.
Fixed in HEAD. From what I saw in my testing this introduced around 200ms (on my machine) on second startup, but a truly massive amount of overhead (e.g. multi-second) on the first start. Great catch John.
Unfortunately there was no net improvement with this fix, because now another bundle pays the manifest localization hit (see bug 272087). I think we won't see the benefit from this fix until that other bug is also fixed.