Comment 1 Tim deBoer 2009-10-05 11:54:52 EDT

This just happened again on a cold-start. There were no changes on disk but p2 took 1m 30s of CPU time before the workspace selection dialog appeared.

Comment 2 Ian Bull 2009-10-16 01:26:08 EDT

Do you have lots of things in an extension location (dropins for example)?

Seems related to Bug 275274.

Comment 3 Tim deBoer 2009-10-16 08:41:35 EDT

If I understand the way IBM adopter products are configured, I either had 4 or 0 dropin plugins. While the repeated error messages are an issue, my main concern is the horrible and unpredictable performance.

From further use, I've found that when I make a change (e.g. add a temp fix, or add the core tools) p2 usually doesn't pick it up on the first start (!), takes 1m26s CPU time to start the second time, and then randomly takes this long again on the third or fourth start.

Comment 4 Tim deBoer 2009-10-28 15:16:43 EDT

Since there are two issues here, I am splitting this bug into two bugs. Bug 293608 tracks issues with reconciling (both not happening on first start, and happening again unnecessarily), and please use this bug to track the performance issue.

The adopter product I'm working on has ~2000 plugins, and reconciling on 3.4 takes around 8 minutes of CPU time on my machine. It's great that the performance has been reduced to 1m30s CPU time in 3.6, but this is still horrendously long to update a single plugin with no dependency changes. Worse, to the user Eclipse appears to be hung during this time.

If the performance in cases like this can't be improved by an order of magnitude, we need to look at optimizing for different cases. Users add new features or apply compatible updates to existing plugins very frequently, and there is absolutely no reason why this should take more than a second. I can understand why updating a large set of features would be more complex, but even here there are many cases where the update is compatible and an entire plugin reconciliation is unnecessary.

Comment 5 Mike Wilson 2009-11-23 16:44:49 EST

Obviously, there are two issues here:
- There are still long delays happening (1:30 is *long*) at unexpected times.
- There is no feedback when this happens.

I don't know anything useful about the first part of the problem, but there should never be a case, regardless of the size of the datasets, number of plug-ins, memory constraints/etc. where Eclipse hangs for a minute without feedback, regardless of what operation is being performed. Is it possible to do something with a splash handler (or whatever) to let the user know what is going on?

Comment 6 Andrew Niefer 2009-11-23 17:16:53 EST

(In reply to comment #5)
> Obviously, there are two issues here:
> - There are still long delays happening (1:30 is *long*) at unexpected times.
> - There is no feedback when this happens.
> 
> I don't know anything useful about the first part of the problem, but there
> should never be a case, regardless of the size of the datasets, number of
> plug-ins, memory constraints/etc. where Eclipse hangs for a minute without
> feedback, regardless of what operation is being performed. Is it possible to do
> something with a splash handler (or whatever) to let the user know what is
> going on?

There is bug 225150 regarding feedback in the splash screen.  This occurs before we get to the workbench and will require using SWT and registering a service under the StartupMonitor interface.

Comment 7 John Arthorne 2010-02-23 16:31:37 EST

I'm marking this as a duplicate of bug 251561 because they are the same issue: reconciler performance problems in a product with a very large number of bundles installed via reconciler-based mechanisms (dropins and platform.xml).

*** This bug has been marked as a duplicate of bug 251561 ***