| Summary: | [prov] [ui] Opening the admin ui or the end user ui takes a long time | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | Incubator | Assignee: | equinox.incubator-inbox <equinox.incubator-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.arthorne, susan |
| Version: | 3.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Pascal Rapicault
The repositories are lazily loaded, but the UI references them immediately when populating the repository views in the admin UI, and the "available features" pane in the end user UI. Just to clarify, when you say it takes a long time opening the end user UI, do you mean startup of the workbench takes a long time, or opening Help > Software Updates (Incubation) takes a long time? In the case of the admin ui, the workbench window takes a long time to show up. In the case of the user ui, it is the dialog that takes a long time. Ok, that matches my expectations. The end user UI is not likely to get any better as is because we always show the content of repos (we don't make the user expand the repos). Unless we want background access the repos at some point... There is some improvement that could be done in the admin UI...holding onto URLs vs. metadata repo instances. Last week I was waiting for an addRepository API before doing the cleanup and then didn't have time to get back to it. Unless someone objects, I want to deal with this in M5 while also dealing with the ramifications of not being able to hold onto Profile instances. > The end user UI is not likely to get any better as is because we always show
> the content of repos (we don't make the user expand the repos).
When I open the end user UI now, I don't see the repositories being expanded automatically. You do however need to load the repository currently in order to see the repo name, but that information can be obtained without loading the repository if needed (it's stored in preferences).
The end user UI doesn't show the user repos in the "available features" list. It just shows the categories. It gets all categories from all repos up front, and to find all the categories it has to go through everything. That's what I meant by "we always show the contents of everything". So even if those categories are not open/expanded, it took a trip through all of the IUs of each repo just to assemble that top level list. (If a repo has no categories, I name the "uncategorized" category with the repo name, otherwise we'd have a bunch of duplicate "uncategorized" categories). That's probably what made you think you were looking at a list of repos. Unfortunately, this performance is about to get worse in M4 due to bug #211521. I will have to take several passes through each repo in order to collect all of the uncategorized elements. I'll explain more fully in that bug... Sorry, ignore comment #5... I was thinking of the admin UI. This was resolved already with background fetching of repo content *** This bug has been marked as a duplicate of bug 212775 *** |