Bugzilla – Full Text Bug Listing
| Summary: | [client] Severe scalability problem with multi-select in navigator | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> | ||||||
| Component: | Client | Assignee: | Susan McCourt <susan> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | ||||||||
| Version: | 0.2 | ||||||||
| Target Milestone: | 0.2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
John Arthorne
Created attachment 195425 [details]
Screen shot
You can see the file layout in the screen shot. If I "go into" the images folder, I can then select all files. So, it seems to be a function of the number of parents, siblings, etc.
Setting to major. This crashed FF4, and gave me the "Aw, snap" screen in Chrome. Created attachment 195426 [details]
Error page
I should cap the number of suggestions. From a UI point of view, it doesn't help to crowd a ton of choices in a menu anyway. The fact that we are repeating these computations as the selection changes (rather than waiting until the user opens the menu) is covered in bug 338887. Another possible simple optimization is to only compute suggestions for one file in any given directory. Presumably all files in the same directory will have the same suggestions. Whether I have one file or a hundred files selected in a folder, the suggestion computation should be similar. For my win7 box on FF4, the "crap out" was at about 45 selections. In fact, my browser hung, and since the selections were remembered for me by Orion, I hung again when restarting the navigator. fixed by capping in both ways discussed. - since we only care about the parent of a selected file, we need only consider the first file encountered in each folder. - having eliminated all files with duplicate parents, it's still too crowded to build a menu with every possible parent/child/sibling of the selections in it. Capped it at 5. (In practice, many of the selected folders *are* siblings or parent/children so capping it usually just caps the redundant comparisons rather than taking away possible choices.) I found a bunch of other redundant/embarrassing things such as stripping the same file path over and over, recomputing the roots too many times, etc. That said, you can still get a small "hiccup" every 8-10th selection that feels like a gc. But you don't hang. I'm marking this bug fixed because two more things will improve this: - in bug 338887 we won't do computation until the menu opens so this work won't be repeated every time an item is selected. - in bug 343625 we'll hook in the directory prompter. Once the user can select any directory, I plan to greatly reduce the number of choices shown in the menu. . |