Community
Participate
Working Groups
We must check if the goto/open resource dialog scale. I.E. test it with a workspace 10 to 20 times bigger then normal. How long does the user have to wait if the workspace has a lot of files.
Should check using the big workspace at: http://www.eclipse.org/eclipse/development/performance/
Should also avoid populating the list until a prefix has been entered, as with Open Type.
John recently made some improvements to marker retrieval performance which we might be able to exploit. Basically it still visits each element in the workspace, but avoids creating path or resource objects for each element, only the ones that match. It would be good if the Core support for this was made available as API, and was general enough to allow prefix and/or pattern matching on the simple name of a resource.
I have created bug 27948 for potential new core API to make this faster. It would be interesting to know what information you would need for this case. The less information we provide, the faster it would be.
Tried to use the big workspace, but was unable to get it to start (kept getting select JRE dialog). Have experimented with the following: - change the code to only match when a pattern actually exists (i.e., do not return all resources if no string is entered) - changed the case where no '?''s used and only one '*'s exists at end of match string to use a binary search to get the matches This makes things zippier. Performance is comparable to OpenTypeSelectionDialog for the above case. The code needs to be profiled to see where the time is being spent. I think it is in the matching, not the initial sorting/creation of resource descriptors, so it may be that the core PR would not be as helpful as expected.
Released changes for the items I mention above. Did do some profiling, but it was hard to pinpoint what was taking long during the Open Resource operation due to all the other background stuff that is going on (e.g., java reconciling, label decorators, etc.). Leaving open in order to further investigate the filtering mechanism that Open Type is using.
Tried using the "fast visitor" given the current design of the OpenResourceDialog, which sorts the resources up front. For this approach the path of the resource is needed so that it can be instantiated when it gets displayed in the dialog (i.e., need to get the resource image - at which point the real resource is needed, not some lightweight version of it) and when it gets selected (i.e., so parents can be displayed and/or it can be returned when the dialog is closed). Based on my timings it actually takes longer to use the resource visitor in this instance. Investigate using the fast visitor everytime the person types a character (i.e., no longer sort the resources up front). Observations about time issues: - Opening the dialog currently using big workspace takes about 1.5 seconds - Typing a complex match string (one that cannot take advantage of the sorted resource list) is pretty unresponsive. The dialog updates one at a time in spurts. The behavior is much less responsive than the OpenType dialog for the scenario. - A large part of the time spent when typing a character is updating the dialog. Majority of the time is spent in Object.wait, due to syncExec. This is the same case with the OpenType dialog when typing, but as indicated OpenType dialog seems more responsive for complex match case. It may be that it just has less items to look at. Need to investigate this.
Note, there is a functional reason to have all the items sorted ahead of time - it allows "smooth" filling of the matches list. If all items are not sorted from the onset, as the match operation occurs items will be added to the list "out of order" which will look odd and which will lead to jumpiness of the list/scrollbar (as things are added randomly to the list). I did track down why the dialog is less responsive than the OpenTypeSelectionDialog. The OpenTypeSelectionDialog subclasses the TwoPaneElementSelection dialog, which uses a FilteredList, which updates the table and/or matches quicker. Did try subclassing ResourceListSelectionDialog from TwoPaneElementSelection dialog and response for updating the matches list as one types is better. This approach also requires much less code (most of what the ResourceListSelectionDialog does is handled by TwoPaneElementSelection). Still, per NE, looked into using fast visitor to get the matches and then sorting the matches each time the user types a character. Response time seems acceptable with big workspace. If the pattern string is a "derivative" of the previous pattern string, I use the existing matching resources for matching with the new pattern string. So entire workspace is not necessarily visited on each keystroke.
Released changes in build > 20030122.
What about keeping that list after the dialog is opened and update it with a resource change listener? So the second time the dialog is opened it will be faster.
Keeping the list would still cause a delay the first time the dialog opens, but that's how OpenType works, The approach would also require more memory in the big workspace case. I think the approach Nick suggested is acceptable. Did you try the new code in big workspace? Anyway, I think the performance was improved and I need to focus on other things at this point. If you want to reopen the bug report, go ahead, but I'm not planning on doing anything more on this for M5.
If this is revisited in the future, keep in mind there is a space overhead with maintaining a separate list of every resource in the workspace. Each resource handle uses about 70 bytes of space over what is maintained by the core resource tree. As it is now, every time I open this dialog, memory usage jumps by a couple of megs. Watch mem usage in the task manager when you open this dialog a dozen times on windows. To make this dialog *really* efficient, you'd have to avoid creating IResource handles completely. All this dialog needs is the simple name (a String, which core already maintains), and an image (most of which are duplicates). It should be possible to have *very* low space overhead for this dialog. Note you can obtain the image for a file name without creating a resource handle using IEditorRegistry.getmageDescriptor(String name).
Changes break JDT. Backing out changes. Need to get with JDT to see how we can use fast visitor for their case. They are doing more filtering than just IResource.type and pattern string. Changes for the faster dialog are as follows: GotoResourceAction 1.4 GotoResourceDialog 1.5 OpenResourceDialog 1.3 OpenWorkspaceFileAction 1.4 ResourceListSelectionDialog 1.4
When put changes back in, make sure folder list sorted correctly. NE tried out new code and noticed that folder list is sorted in reverse order.
If we go with hybrid approach for jdt, need a wait cursor.
Waiting on [Bug 30274] for a solution for JDT.
Released hybrid solution. Fixed folder sort problem.
