Community
Participate
Working Groups
Build ID: Eclipse 3.6m5 Our tool on top of Eclipse uses several extension locations referenced by *.link files in a links/ folder. When analyzing startup performance of our tool, we noticed that we can gain 2.5 sec performance improvement (as well as reducing the number of disk accesses by 50%) by doing this: 1. Ensure that org.eclipse.update.configurator is autostart=off in bundles.info 2. put our *.link files into a dropins/ folder rather than links/ It looks like as long as our *.link files are under links/, the update.configurator still performs a lot of extra work, even if it is not auto-started. I am wondering how we could benefit from the performance improvement, but still keep our *.link files in links/ for backward compatibility, since p2.reconciler.dropins can use them from there perfectly well. The extra 2.5 sec performance hit feel like a bug. What extra work does the update.configurator perform? Is that extra work necessary when p2 did the work already? Do we have to physically remove the org.eclipse.update.* bundles from our configuration, and what would that mean? Or would it be possible to keep the o.e.update.* bundles in our config "just in case" but have them inactive? A quick search for related bugzilla's yielded bug 236107 comment 2, and bug 204999 comment 3. Could we get rid of all o.e.update.* stuff in Eclipse 3.6? Or is "promiscuous install" still needed? Until recently, I did see few (very few) update sites which could only be installed through "classic update", but these seem to be going away.
Do you have org.eclipse.update.reconcile=false set in your config.ini?
Yes we do, still we observe the 2.5sec performance hit. FYI, we have around 900 bundles in total, around 700 of them in .link locations with only the core Platform not in a .link.
It looks like this code is called in the PlatformConfiguration#startup method. Perhaps we could get away with a lazy initializer in #getCurrent.
Created attachment 160808 [details] Potential fix I think it shouldn't even be doing this link analysis when org.eclipse.update.reconcile=false, because p2 will be doing all this analysis and updating the platform.xml already. Looking at the code in PlatformConfiguration.configureExternalLinks(), all it does is parse the links and make sure they match what is in the platform.xml (which will always be true if p2 is reconciling). Here is a potential fix that removes this link analysis when org.eclipse.update.reconcile=false. I tried some simple tests with link files and it is all still working correctly. Martin, do you want to give this a try in your product?
(In reply to comment #4) > Created an attachment (id=160808) [details] > Potential fix This works nicely! It gives us the same performance gain as renaming "links" to "dropins".
There is one thing which puzzles me. Even if we set autostart=false for the org.eclipse.update.configurator bundle in the bundles.info of the installation, the bundles.info created in the user configuration area has the autostart flag set to true again. I have no idea why or how this flag changes.
Since the fix is verified to work perfectly fine, is there a chance getting this released into 3.6m6 ?
(In reply to comment #7) > Since the fix is verified to work perfectly fine, is there a chance getting > this released into 3.6m6 ? Note that as far as I can tell, the real fix in attached patch is just 2 lines of code which look absolutely reasonable. All the rest is just formatting changes.
DJ has just been doing some additional testing on this to make sure none of the legacy update manager scenarios are affected by the change.
DJ, I have tentatively marked M6 but if you see any risk here we can move to M7.
I need to do some additional testing as I ran into another problem since my example site had a space in the URL. (bug 304895)
Ok, I think this is good for M6. John or Andrew, please release the patch to HEAD and tag the update.configurator bundle for the next build. Thanks.
Released. Thanks for the extra review and testing DJ.
Awsome. Thanks all!
