The location bar autocomplete hangs after first character is type; regardless of speed of character input. Presumably while it is searching through my autocomplete history. Reproducible every single time and its driving me crazy. This started after the patches that change the way autocomplete worked where it nows searches titles and addresses.

This may be a dupe of Bug 373256 but I never noticed this until after the landing of Bug 389491. May just be a conicidence that my history got large enough just after that landing?

kurt, thanks for logging this spin of bug from bug #389491 can you provide some details, like: 1) the amount of ram on your machine 2) how much history (in days) you keep 3) the size of your places.sqlite file

1) 512MB RAM 2) 30 days history 3) 11MB (11,296 KB) 4) CPU is an AMD 64bit 3200+ Athlon 5) running Windows XP SP2 (32bit)

the problem is actually exist since sqlite is being used. but in last days it hangs after every typed character. even if it something at the end of address. 1) 4096MB 2) 999 days 3) places - 551MB, urlclassifier2 - 6,8MB, formhistory - 933KB, cookies - 189KB 4) E6750 @3.4GHz 5) Windows XP x64 it's clearly sqlite is guilty in most of hangs related to places: loading takes half a minute, closing takes 10 minutes, cookies disappears constantly, history takes ages to open, addressbar autocomplete is completely unusable etc etc etc

thanks Kurt and Coth for the details. I can't speak about cookies (can you log a spin off bug on what you are seeing?) As for your performance problems with the url bar, we have code to set the cache for sqlite that currently does 6% of the physical ram on your machine. (http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsNavHistory.cpp#627) for kurt, 6% of 512MB is 30.72 MB. kurt, can you try something? can you try setting the hidden integer pref "history_cache_percentage" to a bigger number (like 25) and report back if that has helped? Can you see how much RAM firefox.exe is already using? Can you tell if we are already swapping out to disk? for coth, 6% of 4GB is 245.76 MB. for your 551 MB places.sqlite, that exceeds our cache. 999 days of history and a places.sqlite of this size will be a serious problem for us. I'd be very curious to know the break down of your places.sqlite. specifically, the size of your moz_historyvisits, moz_places, moz_favicons, and moz_bookmarks tables. brettw (in several bugs) has warned us about what would happen when we exceed the db cache.

well actually cookies started disappear just a few weeks ago in august. definitely in august. still can't understand how it happens, but have feeling something is not being saved when ff crashes at closing. as of other things - they were exists for ages. my moz_places table right now compromising of 546000 records starting from about march 2005. moz_historyvisits - 700000 records. moz_favicons - 2762 records, moz_bookmarks - 474 records. I don't know unfortunately if there is any ability to get size on disk of each table in sqlite. I just checked - i actually have history setted to 9999 days, not just 999;)

Sorry I have no clue about swapping out to disk. Both tests performed with extensions disabled, default theme, about:blank loaded on startup and waited a min or two until it felt safe that firefox stopped (I guess) checking for safebrowsing updates. Restarted firefox between tests. Test 1 was performed with the default 'history_cache_percentage'. Test 2 was performed with 'history_cache_percentage' set to 25. STARTUP TYPED 'a' BACKSPACE THEN TYPED 'b' 1) 26,544 K 34,412 K 35,868 K 2) 26,140 K 34,412 K 35,868 K Same exact results other than the startup.

Are you sure this only happens from 2007-08-21 when bug 389491 was checked in or were there checkins earlier from this bug? Here the problem started around the beginning of July (unchanged in seriousness). In happens irregularly and I can't deliberately reproduce the problem. RAM memory: 512 MB, history remembered for 60 days, places.sqlite file is 21 MB.

I not sure which day this started because I was on vacation then but it was after the landing bug 389491.

Alright it was a coincidence that this started after that bug landed. I deleted a crap load (like a couple hundred) URLs out of my history via (ctrl+delete) from the location bar autocomplete and now I'm not having any hangs. So this is a dupe of Bug 373256 but I'll let someone else make that decision and also another reason to not have history set to 180 days by default...remember mine is only set at 30 days.

coth, are you still seeing cookie disappearances? if so, can you give me any more details - does it happen consistently (every shutdown), during a session, or only when the browser crashes or is terminated? are you switching back and forth between a current release (2.0.x) and trunk, using the same profile? do they all disappear, or only some?

i don't know what was happening. but cookies table was full of cookies. so definitely not all of them was disappearing. i don't see this problem for over a week now. but in august it stably was happening several times per week. once session started old cookies wasn't available on many sites. for example. i set my settings on google search, but once this thing happened my settings does not work any more. google just show results in default settings and i need to set up them again. at the same moment it happens to most of sites, where i have settings in cookies and forums that saves session information into cookies, so i need to login into forums again. a week ago i didn't found anything related to this in bugzilla, so i suspect it's a rare thing happens to users with big places. i have no ff2 on this pc. mozillazine doesn't work for me, so i'm not in news, but i've just updated to 2007090604 from about a week old build and locationbar is seems to be much better now with dynamic search.

So, is this a dupe of bug 373256? Can we get a confirmation that we're not seeing complete hangs when people type in the locbar with large histories? I don't think we can ship B1 with that sort of perf hit.

Mike I ctrl+deleted about 500 links out of my location bar autocomplete menu and now I do not have this problem. Everytime the location bar starts to hang, I ctrl+delete a couple hundred more. Very annoying that I have to do this especially since my history is only at 20 days (30 at home). Mike, in my opinion this a dupe of bug 373256. What do you mean by "get a confirmation that we're not seeing complete hangs when people type in the locbar with large histories" that is what this bug comes down to I'd think...along with the bug 373256. To summarize: if Firefox was remembering less addresses than I wouldn't have had this problem. Mine is set at max 30 and I can't imagine the slowness this would have been if I had 180 days worth.

Autocomplete perf got a lot worse with the fix for bug 389491, so I don't think this is a dup of bug 373256. But if the fix there helps enough, this might not continue to be a problem.

Just for confirmation, the problem is not reproduced when the cache is cleared, but for the previous build (3.0a8pre), I had this problem even with the smallest of entries in the location bars AutoComplete history. I had enabled the clearing of history data as a workaround. Just like Google Suggest, it needs to run in a seperate thread (If suggest does not do this, AutoComplete should still run in a seperate thread, as with any CPU hungry application). Maybe someone could compile a build in which it does this and tell us the results?

Still targeted for M9?

bug 401726 was checked in, and i'm not able to reproduce this hang with that patch applied (and after a shutdown/restart). that said, i was never able to reliably reproduce this one to begin with, seemed to randomly happen. could some of you who can reproduce please test this w/ an hourly or tomorrow's nightly?

Looks fixed with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9a9pre) Gecko/2007110103 Minefield/3.0a9pre ID:2007110103 but hangs when pause typing (while pondering search i think). Kind of annoying (but really better). This could be a new bug. Any ideas ?

bug 401722 has been checked in, which should resolve, or at least improve this.

I was reliably reproducing it, Mac at home and Windows at work, before bug 401726, and haven't seen a single one since. You've got my vote for "fixed by the combination of..."

Bug 401726, bug 401722 and bug 381795 were all aimed at this bug. I'm going to close it if no one else can reproduce it.

Performance is acceptable for me in today's Mac nightly. There's a short pause (slightly less than one second) after I type the first letter, but it doesn't lag at all while I type the rest. It's still laggy in a debug build, but I guess that's what I get for using debug builds.

Given multiple verifications and an absence of anyone able to reproduce, i'm closing this.

WFM with nightlies on Mac and and Win XP. XP has 15000 history entries.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv