Summary: | [dstore][regression] Right-click > Move on a file is extremely slow and blocks the UI | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] Target Management | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||
Component: | RSE | Assignee: | David McKnight <dmcknigh> | ||||
Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||
Severity: | critical | ||||||
Priority: | P1 | Flags: | mober.at+eclipse:
review+
|
||||
Version: | 2.0 | ||||||
Target Milestone: | 2.0 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Bug Depends on: | |||||||
Bug Blocks: | 190803 | ||||||
Attachments: |
|
Description
Martin Oberhuber
2007-05-30 15:50:08 EDT
The dialog even did not go away when I killed the remote server: When killing it, I did get another dialog telling me that the connection was canceled, but the "Move" dialog stayed there, blocking all of Eclipse. I firmly and honestly believe that all remote operations must be done in background threads; and, the "Move Destination" dialog must be fixed to look as it was in RSE 1.0.1. When trying this again, I notice that the "Move To" dialog actually did have both the "My Home" and "Root" filters, but it was preselected on the parent directory of my homedirectory: So it had expanded the "Root" filter with a preselection on /folk. Two problems with this: * Expanding Root was very slow * for /folk it's not even correct since no children are shown It should have preselected the "My Home" filter as move destination, i.e. the very same directory that I had selected as move source. Fixing this would fix the regression, then the other issue can probably be deferred to 2.0.1. As far as I know, the move dialog hasn't been looked at in some time so hopefully fixing this will be straight-forward. I don't see a performance issue when I try this. Is the primary issue here that the expansions are done on the main thread? One thing about this dialog (in doing pre-selection) is that it avoids deferred queries in order to deal with the widgets directly. To change that would be dangerous at this point. Maybe to avoid the performance hit we should not provide preselection in this case. What do you think? The primary problem is that way too many remote queries are made, for directories that are not needed and not related to what the dialog should do. If I wanted to move "My Home"/folder somewhere else, it should preselect "My Home"/folder and nothing else. It can query the parent directories of "My Home", but given that "My Home" is /folk/mober it should definitely NOT query whether /folk/foobar has children or not. But that's what it has been doing for me, and because /folk contains hundreds of directories in hundreds of file systems potentially far away, the dialog has become unusable. Created attachment 69720 [details]
patch so that directories that are the filter directory match the filter
Martin, does this patch help in your scenario?
Patch is good, please apply -- it fixes the immediate issue. But when reproducing it, I still fell into other issues, so it's not yet fixed sufficiently. The new issues are being tracked in bug #190803. I've committed the fix. [target cleanup] 2.0 RC2 was the original target milestone for this bug |