Community
Participate
Working Groups
Consider the attachment in bug 239529 (https://bugs.eclipse.org/bugs/attachment.cgi?id=106963) for 3.4.1. +++ This bug was initially created as a clone of Bug #239529 +++ In the planner when calling attachCUs we use the equinox resolver. While profiling large installs I noticed a lot of overhead associated with adding objects to the VersionHashMap it uses. In installs with many IUs this ends up dominating the time spent in the planner. It looks like we're ending up adding a number of the identical meta capabilities that we're using as tags and this ends up causing problems. The VersionHashMap keys off the capability name which is always the same for these meta capabilities. The VersionHashMap value is a sorted array of the capabilities that unfortunately gets re-sorted every time a new entry is added and this ends up being expensive when each IU provides the identical capability. Here's a list of capabilities that I noticed are causing problems: <provided namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' version='1.0.0'/> <provided namespace='org.eclipse.equinox.p2.localization' name='df_LT' version='1.0.0'/> <provided namespace='org.eclipse.equinox.p2.eclipse.type' name='source' version='1.0.0'/> Talking to John, short term we might want to filter these out in the planner. Longer term we might want to make these capabilities more unique.
Patch has been released to 3.4 maintenance branch.