When I start up my computer for the first time and click on the autocomplete arrow it takes several seconds to draw. You see the first line appear, then the second line, the third line etc., and finally you see the scrollbar appear. The next start up requires less patience, although the machine obviously is grubbing to display the text. When I want to scroll down or up with the slider, the text scrolls but the slider has delay and sticks to the top or bottom for one or two seconds. I didn't have this problem (not at all) with the previous autocomplete.

Does the build you're testing include the patch from bug 406259?

ria, is the same scenario slow if, instead of clicking on the autocomplete arrow, you type the letter "h"? the query for the arrow is different than the chunked autocomplete query, so it could be the cause http://lxr.mozilla.org/mozilla/source/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp#444 and this might not be related to the autocomplete.xml code at all.

The build I tested should contain the patch of Bug 406259. Typing letters feels indeed different; then the autocomplete reacts faster. The scroll problem makes me think of the scroll behaviour in the add-ons manager.

global frecency should make this very fast, see bug #394038

will be fixing this along with bug #394038

note, this might already be fast due to recent changes from Marco. see bug #392399. ria, can you confirm?

Something before 1-1-2008 made it already faster and latest trunk opens the menu in less than 1 second. My places.sqlite is about 10 MB at the moment.

this is going to be fixed along with bug #394038 note, one reason it will be fast is that we will be showing typed sites ordered by frecency, not visit date. see bug #411293

please see https://bugzilla.mozilla.org/show_bug.cgi?id=412730#c13

This is fixed by bug 406359 which does the chunking and early quitting if we have enough results.