This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | [69cat] First Qsearch is slow | ||
|---|---|---|---|
| Product: | platform | Reporter: | Ondrej Langr <olangr> |
| Component: | Quick Search | Assignee: | Jan Becicka <jbecicka> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | anebuzelsky, dankata5000, doctorlux, fleka, gustavo.nv, hellochar, hmichel, jbecicka, jmichelberger, johnjullion, karel_barel, leo75, michael.nischt, misterm, onmomo, stefpet, tnleeuw |
| Priority: | P2 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 176794, 176898 | ||
| Bug Blocks: | 134398, 190448 | ||
I think this is not fixable in the way you suggest, I'll try to explain - current state isn't good, there is something eating the time during first invocation of Qsearch. Probably it's class loading and other init tasks, which would stop "Searching..." label from being displayed anyway. So proper fix is to get rid of initial delay completely, then there is no need for progress info. Only if this approach fails, then I could try something with progress info. Thanks for explanation. I totally agree, no delay is for sure better than delay with proper indication ;) However, if we will eventually have searching through web tutorials as drafted in the storyboard, this action would most likely require such indication, so I thought it could be good to have this infrastructure. Yes, agreed - for slow providers like web based ones, there will have to be progress info in their section of results popup window - but that will be yet another issue, this one is more about slowness of infrastructure itself, not individual providers. OK, probably two different things. I'm making this a defect regarding slow first use. See enhancement #137938 for the "Searching..." indication. Just note that this one will be probably very hard to fix. *** Bug 176652 has been marked as a duplicate of this bug. *** Whoa .. this issue seems to have over a dozen duplicates (including duplicates of duplicates) and an impressive number of CCed people. Any change to fix for 6.9? Ondro, is this duplicate of 190451? I don't think so. 190451 is about "responsiveness" - i.e. how well quicksearch communicates that it is ready to accept input.
This issue is about both responsiveness ("without providing any indication that something is going on") and performance ("first invocation takes significant amount of time").
so the first part is duplicate of bug 190451 and the second part duplicate of bug 176898. ? Changeset: http://hg.netbeans.org/jet-main/rev/60004bb454b6 Author: Jan Becicka <jbecicka@netbeans.org> Date: 2010-10-27 14:49 Message: First Qsearch is slow #176794 #137829 #176898 Issue #137829 - [69cat] First Qsearch is slow Integrated into 'main-golden', will be available in build *201010280000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/60004bb454b6 User: Jan Becicka <jbecicka@netbeans.org> Log: First Qsearch is slow #176794 #137829 #176898 Issue #137829 - [69cat] First Qsearch is slow |
Currently, the first invocation of QuickSearch takes significant amount of time (in the full IDE), without providing any indication that something is going on, which gives the user the feeling that the IDE is "frozen". A decent indication ("Searching..." label inside the results window) within less then 1 second is necessary to provide feeling of responsiveness.