Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. Add update site http://andrei.gmxhome.de/eclipse/ 2. Choose to install Bytecode Outline under Eclipse 3.4 plugins 3. A modal dialog about Checking Required Dependencies will appear. The dialog remains up for approximately 15 minutes, then the plugin install pages appear. The problems are: 1. 15 minutes is too slow to prepare to install a simple, small plugin. 2. There is insufficient indication of what the dialog is actually doing. 3. A dialog that can displays for 15 minutes should not be modal. The update process should support background operation, so I can keep working. 4. In the lower RHS corner various jars seem to be downloaded. No explanation is provided as to why these jars are being downloaded and they are obviously not the requested plugin. - The download URL is displayed truncated in status bar. It would be much better if displayed in the dialog and in non-truncated form. - The downloads all seem to be from "downloads.ecli...". Gven that the plugin Im installing comes from "andrei.gmxhome.de/eclipse/", why does the installer need to access "downloads.eclipse.anything"? It makes me suspect it is doing unrelated refreshes of other update sites, which would be fine if it was not so obstructive and slow. 5. On my first attempt, I hit the "Cancel" on the dialog after 5 minutes of no progress. 3 minutes later, no cancel had occurred so I killed the Eclipse process. There is no point having a Cancel button unless it actually Cancels within approx 20 secs. I suspect my report will be marked "Cant Reproduce". Fair enough, but this is an actual user experience with P2 "in the wild", its not pretty, and perhaps explains why there alot of user frustration currently with Eclipse's Software update process. More information: Slowness appeared to be due to network latency in getting Jars, not local paging on machine.
Hi, Ben. We definitely understand the frustration and have focused on these issues in 3.5. I know this doesn't help you on 3.4.1, but I will point you to the relevant bugs. The primary issue is that the very first time an update site is encountered, the metadata must be downloaded and in some cases updated to p2 format. (I know, the worst performance is at the worst time - first impression). To make it worse, the very first install causes you to contact every single repository. This is the source of the 15 minutes. > The problems are: > 1. 15 minutes is too slow to prepare to install a simple, small plugin. Lots of different performance fixes have contributed to a better experience in 3.5 (too many to name). Worth mentioning is bug 266939. > > 2. There is insufficient indication of what the dialog is actually doing. Bug 236495 (that bug is not about the indication, but moving to background processing allows the platform progress indication details to show in the dialog). > > 3. A dialog that can displays for 15 minutes should not be modal. The update > process should support background operation, so I can keep working. Bug 236495 > > 4. In the lower RHS corner various jars seem to be downloaded. No explanation > is provided as to why these jars are being downloaded and they are obviously > not the requested plugin. > - The download URL is displayed truncated in status bar. It would be much > better if displayed in the dialog and in non-truncated form. Fixed as part of bug 236495. > - The downloads all seem to be from "downloads.ecli...". Gven that the plugin > Im installing comes from "andrei.gmxhome.de/eclipse/", why does the installer > need to access "downloads.eclipse.anything"? It makes me suspect it is doing > unrelated refreshes of other update sites, which would be fine if it was not so > obstructive and slow. This is bug 266939. > > 5. On my first attempt, I hit the "Cancel" on the dialog after 5 minutes of no > progress. 3 minutes later, no cancel had occurred so I killed the Eclipse > process. There is no point having a Cancel button unless it actually Cancels > within approx 20 secs. I can't find the bug number easily, but this has been fixed in 3.5 in the underlying transport layers. > > I suspect my report will be marked "Cant Reproduce". Fair enough, but this is > an actual user experience with P2 "in the wild", its not pretty, and perhaps > explains why there alot of user frustration currently with Eclipse's Software > update process. > Unfortunately it is quite easy to reproduce, and much of our efforts in 3.5 are focused on these problems. The impact on users is less noticeable on fast connections when there are responsive sites, in particular when the sites have native p2 metadata. But as you say, this is not the experience "in the wild." Hence our efforts since releasing p2 into the wild have been focused on this. As your bug title indicates, there are multiple problems involved, but I'll mark this as a duplicate of bug 266939 for the purposes of bug accounting. *** This bug has been marked as a duplicate of bug 266939 ***
