| Ganymede desparately slow when setting target platform [message #17320] |
Mon, 25 August 2008 07:03  |
Eclipse User |
|
|
|
We have an OSGi-based application made up of several hundred plugins, test
and production. On start-up, Ganymede is eating CPU - to the point where
it is almost unusable. Once started - which takes 2+ hours - it works
fine.
To work round the issues, devs are keeping Eclipse open. Alternatively,
we have to:
- move the workspace to the side
- recreate the workspace, copying over the old .metadata and target
platform project
- restart Eclipse and set the target platform
Setting the target platform alone takes 15+ minutes, during which time the
CPU is pretty much maxed out. Once the target platform is set, the
remaining projects can be re-imported in a matter of minutes.
The problem occurs both on Windows and Linux.
Can I ask, are other people seeing this? What can I do to mitigate the
problem, other than go back to Europa? (It's making our lives somewhat
irksome at the moment.)
Tara
|
|
|
| Re: Ganymede desparately slow when setting target platform [message #17917 is a reply to message #17320] |
Wed, 27 August 2008 02:04  |
| Eclipse User |
|
|
|
Originally posted by: zx.code9.com
Tara Simpson wrote:
> We have an OSGi-based application made up of several hundred plugins,
> test and production. On start-up, Ganymede is eating CPU - to the point
> where it is almost unusable. Once started - which takes 2+ hours - it
> works fine.
>
> To work round the issues, devs are keeping Eclipse open. Alternatively,
> we have to:
>
> - move the workspace to the side
> - recreate the workspace, copying over the old .metadata and target
> platform project
> - restart Eclipse and set the target platform
>
> Setting the target platform alone takes 15+ minutes, during which time
> the CPU is pretty much maxed out. Once the target platform is set, the
> remaining projects can be re-imported in a matter of minutes.
>
> The problem occurs both on Windows and Linux.
>
> Can I ask, are other people seeing this? What can I do to mitigate the
> problem, other than go back to Europa? (It's making our lives somewhat
> irksome at the moment.)
I'm confused, is it Ganymede or is it setting the target platform that
is taking forever? I need a bit more details because I can help figure
things out. There are tons and tons of people that use PDE to develop
against target platforms of 10 to 1000 plug-ins everyday. So there must
be something special going on in your case...
Are things on a network drive by any chance?
Cheers,
~ Chris
|
|
|
|
|
| Re: Ganymede desparately slow when setting target platform [message #577360 is a reply to message #17320] |
Wed, 27 August 2008 02:04 |
| Eclipse User |
|
|
|
Tara Simpson wrote:
> We have an OSGi-based application made up of several hundred plugins,
> test and production. On start-up, Ganymede is eating CPU - to the point
> where it is almost unusable. Once started - which takes 2+ hours - it
> works fine.
>
> To work round the issues, devs are keeping Eclipse open. Alternatively,
> we have to:
>
> - move the workspace to the side
> - recreate the workspace, copying over the old .metadata and target
> platform project
> - restart Eclipse and set the target platform
>
> Setting the target platform alone takes 15+ minutes, during which time
> the CPU is pretty much maxed out. Once the target platform is set, the
> remaining projects can be re-imported in a matter of minutes.
>
> The problem occurs both on Windows and Linux.
>
> Can I ask, are other people seeing this? What can I do to mitigate the
> problem, other than go back to Europa? (It's making our lives somewhat
> irksome at the moment.)
I'm confused, is it Ganymede or is it setting the target platform that
is taking forever? I need a bit more details because I can help figure
things out. There are tons and tons of people that use PDE to develop
against target platforms of 10 to 1000 plug-ins everyday. So there must
be something special going on in your case...
Are things on a network drive by any chance?
Cheers,
~ Chris
|
|
|
| Re: Ganymede desparately slow when setting target platform [message #577574 is a reply to message #17917] |
Wed, 27 August 2008 19:16 |
| Eclipse User |
|
|
|
Chris,
thanks for your response.
Several things to report.
The problems largely disappear with a fresh install of Eclipse 3.4. The
system starts-up and allows me to set a new target platform relatively
quickly. We're talking a couple of minutes rather than hours. We also
noticed a considerable difference in performance between Eclipse with 1.6.
and 1.5, the latter being a factor slower. (We knew there would be a
difference, but not this much.)
So it appears I have been somewhat disingenuous in labelling Ganymede as
slow - apologies for that - but the finger does now point to one of my
installed plugins; subeclipse, Spring IDE or Eclemma. These plugins
account for the only differences between the 2 versions of Ganymede. I
intend re-applying these tomorrow, one by one, until the problems
re-surface.
Incidently, with the install of Ganymede that does churn, the problems are
prevalent during Java Tool initialization and during setting of the target
platform. Initializing Java Tools can sit at 1% for an age. A kill -3
stack trace comes back with an almost identical stack trace every time:
at java.lang.System.arraycopy(Native Method)
at java.util.ArrayList.toArray(ArrayList.java:306)
at
org.eclipse.osgi.internal.module.ResolverBundle.getExports(R esolverBundle.java:116)
at
org.eclipse.osgi.internal.module.GroupingChecker.createPacka geRoots(GroupingChecker.java:151)
at
org.eclipse.osgi.internal.module.GroupingChecker.getPackageR oots(GroupingChecker.java:129)
at
org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:285)
at
org.eclipse.osgi.internal.module.GroupingChecker.isConsisten tInternal(GroupingChecker.java:103)
at
org.eclipse.osgi.internal.module.GroupingChecker.isConsisten tInternal(GroupingChecker.java:67)
at
org.eclipse.osgi.internal.module.GroupingChecker.isConsisten t(GroupingChecker.java:52)
at
org.eclipse.osgi.internal.module.ResolverImpl.addConflicts(R esolverImpl.java:720)
at
org.eclipse.osgi.internal.module.ResolverImpl.getConflicts(R esolverImpl.java:711)
at
org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:629)
at
org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:594)
at
org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:539)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
at
org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:573)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
at
org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:573)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles (ResolverImpl.java:501)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolve(Resolv erImpl.java:388)
Even on a clean install we noticed that this gets called several hundred
thousand times. (We compiled the source code and stuck a diagnostic in to
determine this.)
I'll update this thread tomorrow with any new findings.
Tara
|
|
|
|
Powered by
FUDForum. Page generated in 0.15851 seconds
Home