Community
Participate
Working Groups
I20040505 From bug 61311 If i open the Open TYpe dialog and i just type D and then do nothing. The cpu usage of eclipse is going constantly between 50 and 70%. This seems very strange. When this happens JDT has already computed the list of types. I created a performance trace that I will attach. The dialog we use is AbstractElementListSelectionDialog from Platform
Created attachment 10388 [details] A profiler trace
It looks like it it is the creation of table elements that is taking all of the time from your trace (this can be quite expensive for a large list). Can you give me a rough idea of how many entries D will give in your workspace (i.e. will be it be thousands?).
ahh that's it. I thought it never ends.. But it does i just have to wait a quite a bit longer (at least 20-30 seconds) before it goes down. So maybe the number of items you are making there should be maximized, until you start scrolling? But of course it doesn't make any sense for the list to be longer then a few hundred items because nobody is going to scroll through such a list in search for one item.
This is how we limit the size of the tasks view as well - this is also the reason why we open with nothing. Having said that we stop updating as soon as you type a second letter so if the user really want a list that long then we should give it to them. In most cases you will type (or select) fast enough to prevent this problem occuring. I am going to mark this down in priority as there are higher priority performance items to focus on and this is not a regression from 2.1 but a long standing issue. Thanks for the feedback guys - this is very helpful.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
I'll up this one as there is a fair amount of work going into the TypeDialog now. We might want to consider making it VIRTUAL as well as it most cases people will type rather than scroll.
Tod, we should carefully coordinate this effort. I internally implemented a new version of the open type dialog for JDT/UI which makes use of the virtual table. However, the main benefit is that the new dialog doesn't require knwoing all the elements upfront. It directly takes the elements from the search engine and pipes them into a dialog. A non polished prototype of the can be seen in the TypeInfoViewer. The new dialog can be enabled inside OpenTypeAction#run. Please note, that the code in TypeInfoViewer isn't polished yet. It currently post every match into the UI thread. However, the user experience isn't bad right now, except that search doesn't report the matches sorted (but we are working on this). Furthermore, the dialog support a history of the last opened elements and camel case filtering (e.g. OTSD takes you directly to OpenTypeSelectionDialog).
Reassigning to Tod. Pressed the wrong button.
To complete comment #7: the new dialog should allow piping in the results in a sorted fashion via some callback like the virtual table and should not require on the fact that all items are known upfront.
I agree. Let me look at what you did and perhaps propose a patch and get your feedback - thanks for the pointers.
Reducing priority as JDT has thier own dialog now
We can't check this one until Bug 93113 is fixed.
i have to say that the new open type dialog works great! It is fast and calculates the things he doesn't have in the background..
I think we can close this one given the new open type dialog in 3.1. There are still open issues about using the same code in OpenResource, also, but those are documented in other bugs. Closing this one.
