[
https://issues.apache.org/jira/browse/GROOVY-11571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17931843#comment-17931843
]
Paul King commented on GROOVY-11571:
------------------------------------
I created GROOVY-11578 to capture the broken services aspect.
[~emilles] should we close this issue (since reports on the mailing list seem
to indicate that the Fragment Host fix helped with some folks performance
problems) and create another to clean up the excess manifest attributes? Just
to not blur the different aspects.
> Performance problem in Eclipse RCP/OSGi/Equinox environment
> -----------------------------------------------------------
>
> Key: GROOVY-11571
> URL: https://issues.apache.org/jira/browse/GROOVY-11571
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
> Affects Versions: 4.0.25
> Environment: Eclipse RCP 4.25
> Reporter: Torsten Witte
> Assignee: Paul King
> Priority: Major
>
> We have an Eclipse RCP application that includes Groovy (4.0.25) so that
> users can customise it via Groovy scripts (groovy, groovy-datetime,
> groovy-dateutil, groovy-json, groovy-templates, groovy-xml, groovy-yaml).
> Unfortunately, we have noticed that the compilation of each individual script
> takes several seconds (e.g. 3 seconds and more for a tiny script).
> We have discovered that it will be faster if we remove some Groovy libs (e.g.
> groovy-yaml), but that is not an option because we need the dependencies.
> Then we have noticed that the scripts compile in a few milliseconds if the
> application has been started with the Eclipse "-clean" parameter
> ("osgi.clean").
> The scripts can therefore be compiled much faster!
> However, the "-clean" parameter slows down the start of the application, as
> the OSGi configuration has to be recreated each time, and that is also not an
> option for us.
> It seems that Eclipse/OSGi/Equinox holds some wiring information in its
> configuration folder which slow down the Groovy compile times (more precise:
> the class loading).
> When drilling down into the problem, we got as far as buddy class loading,
> where the time is lost.
> The reason is in the {{MANIFEST.MF}} of the {{groovy_<version>.jar}}:
> {noformat}
> Eclipse-BuddyPolicy: dependent
> {noformat}
> Setting the value to "global" fixes the problem and the scripts are always
> compiled in a few milliseconds, whether starting the application with or
> without the "-clean" parameter.
> {noformat}
> Eclipse-BuddyPolicy: global
> {noformat}
> The documentation of the [Buddy Class
> Loading|https://wiki.eclipse.org/Context_Class_Loader_Enhancements#Buddy_Policy_2]
> says:
> bq. dependent - Consults all bundles that directly or indirectly depend on
> the bundle. An indirect dependency can be introduced by bundles that use
> Require-Bundle with the visibility directive set to reexport. Note that this
> casts a rather wide net and may introduce performance problems as the number
> of bundles increase.
> We use Require-Bundle in our {{MANIFEST.MF}} but without visibility reexport:
> {noformat}
> Require-Bundle: [...],
> groovy;bundle-version="4.0.25",
> groovy-datetime;bundle-version="4.0.25",
> groovy-dateutil;bundle-version="4.0.25",
> groovy-json;bundle-version="4.0.25",
> groovy-templates;bundle-version="4.0.25",
> groovy-xml;bundle-version="4.0.25",
> groovy-yaml;bundle-version="4.0.25",
> [...]
> {noformat}
> Are there reasons why the entry "Eclipse-BuddyPolicy" in the {{MANIFEST.MF}}
> of the {{groovy_<version>.jar}} is set to "dependent"?
> Is it possible to set the value to "global" in further releases?
> (Another problem with the Eclipse-BuddyPolicy is described in GROOVY-6491)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
