Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 231532 - Slow go to type waits for all providers
Slow go to type waits for all providers
Product: utilities
Classification: Unclassified
Component: Jump To
All All
: P3 with 1 vote (vote)
: 8.0.1
Assigned To: Tomas Zezula
Depends on:
  Show dependency treegraph
Reported: 2013-06-19 15:10 UTC by Egor Ushakov
Modified: 2014-06-17 15:45 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description Egor Ushakov 2013-06-19 15:10:32 UTC
Steps to reproduce:
- open small java project
- open big c++ project
- try to do "go to type"
As a result request may be really slow even if your requested type exists only in java project because go to type is asking all providers and waits for all of them to return before showing any results.
Comment 1 Egor Ushakov 2013-06-19 15:11:15 UTC
see slowness report in bug 231282, because of c++ slow I was unable to go to java type as well
Comment 2 Tomas Zezula 2013-06-19 16:10:18 UTC
Unfortunately it was a requirement from UI team, the items cannot be added later when user navigates on the list. But it's quite common behaviour on Mac where spot light dynamically changes the list of found items and adds new ones. As the UI team has changed we can try to reevaluate it again. The same holds for Go To File and Go To Symbol.
Petre, what do you think about it? Can I change the behaviour?
Comment 3 Petr Somol 2013-07-08 09:07:39 UTC
With respect to time consuming buildup of lists I believe it is now generally accepted that any available results should be made available to users as soon as possible, but some additional concerns should be taken into account. To make it right, it should be ensured that a result of interest does not "flee" from the user due to the list grow process. In other words, if user has not not touched anything yet, then it is all right to let the list grow in the head, tail or anywhere in the middle, what may shift individual items out of view. However, if the user has selected an item in the list and the list needs grow further, then it should be ensured that the selected item does not move in the view. The list as a whole can then grow before the item or after the item, what would be displayed by possibly changing the items above or below the selected item, and scrollbar would keep adjusting. But the selected item should remain where it is. To make things even easier for the user, it should work like that even if no item has been selected, and the user just has scrolled the list to some position. After the manual scroll, the view should stay focused roughly to the same place even if the list grows further (this is of course tricky to define - which items should be kept in view when the list can grow anywhere inbetween them).

What I described above is the "ideal" state which is followed in some software (I guess MacOS is reasonably good in this respect?), but ignored in other (try Search for file in Windows 7, or open Control Panel - Programs and Features, the growing lists are not very convenient in the respect described above)

Anyway, keeping known results hidden from users does not seem to be defendable, unless there is some extremely serious reason to do so.
Comment 4 Tomas Zezula 2014-06-17 15:45:42 UTC
Fixed jet-main

Fixed as explained, when files from index are known they are displayed.
The file list is then updated by files found by file system crawling.
Comment 5 Tomas Zezula 2014-06-17 15:45:58 UTC
Fixed jet-main

Fixed as explained, when files from index are known they are displayed.
The file list is then updated by files found by file system crawling.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo