Closed Bug 499808 Opened 11 years ago Closed 11 years ago
Long pause before first awesomebar results
Placeholder bug for now. Need to profile to figure out what's going on here, and what we can do about it.
Priority: -- → P2
This seems to be largely fixed now. Testing with my daily-browsing profile (45MB places.sqlite), searches are reasonably quick and responsive, and don't interfere too much with typing. The only somewhat annoying thing is that there's a longish pause before results appear. The browser.urlbar.delay pref is currently set to 1000ms (desktop default is 50). 50 seems too low, but 250 made it faster without seeming to interfere with typing. (The first results still take a second or two to show up, that just might be the current cost of searching on a slow device?) I'd suggest we bump the pref down to 250ms, and call this bug fixed.
Assignee: vladimir → dolske
Attachment #399890 - Flags: review?(vladimir)
Morphing to the current issue; the original concern was likely fixed by bug 455555 and other Places perf work.
Summary: Awesomebar is really slow on Windows CE → Long pause before first awesomebar results
Attachment #399890 - Flags: review?(vladimir) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #399890 - Flags: approval1.9.2+
You need to log in before you can comment on or make changes to this bug.