User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8) Gecko/20100101 Firefox/4.0b8 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8) Gecko/20100101 Firefox/4.0b8 If I leave the History window open with text in the search field, every navigation to a new URL causes Firefox to freeze for multiple seconds before the page even appears, and usually freeze again after the page finishes loading. Clearing the search field or closing the history window instantly restores my performance to what it is normally. Reproducible: Always Steps to Reproduce: 1. Open history window 2. Enter text (any text) into the search field 3. Wait while firefox chugs and populates the history results 4. Navigate to a new page in an existing tab or a new tab Actual Results: Firefox freezes for a while, the page loads, then firefox freezes for a while again Expected Results: No freezes, even if the history window takes a while to update while some sqlite query runs in the background XPerf and VTune profiles show that firefox is pegging a single core during these freezes, with most of the time being spent in sqlite and runtime library stuff (fastzero_I, memcpy, RtlLeaveCriticalSection, etc.) I'll attach screenshots of the xperf profiles, and the compressed .etl file if I can...

Oh, I nearly forgot - the IO spikes pretty significantly during each hang, and the IO during those hangs is almost entirely writes and flushes, not reads, which seems very strange. Here's a graph showing that.

Just tested using the latest nightly; same bad performance characteristics (a short freeze on my initial history search; long freeze before/after each page load). Random data: places.sqlite is 71mb, 112k rows in moz_places, 170k rows in moz_historyvisits Also, couldn't attach the xperf trace - way above the attachment size limit, even if 7zipped. I can probably stash it on dropbox or something if you need it.

Pretty sure we have a bug on this (it's due to us updating the search in the library because you have a new URI).