I was profiling a benchmark (for bug 130078) and I noticed that my build got slower every time I ran the test. The profiles show that the extra time was mostly going into sqllite. I assume this is because of places, but perhaps it's session-restore?

Testcase. Unzip this, run "firefox TpTest/Tp-harness.xml".

Looking at the profiles I'm about to attach, it's definitely places.

The testcase basically reloads the same page a thousand times.

The profiles are too big to attach, even gzipped. But here's the important bits: Early run: index Count Hits Function Name 130048 0 17240 __libc_start_main .... 2007 nsTimerImpl::Fire() 118216 0 2007 nsNavHistory::LazyTimerCallback(nsITimer*, void*) 2006 nsNavHistory::CommitLazyMessages() 1 nsNavHistory::AddURIInternal(nsIURI*, long long, int, int, nsIURI*) Later run: index Count Hits Function Name 130048 0 26714 __libc_start_main .... 11288 nsTimerImpl::Fire() 118216 0 11288 nsNavHistory::LazyTimerCallback(nsITimer*, void*) 11288 nsNavHistory::CommitLazyMessages() In the later profile, all the extra time seems to be going into nsNavHistory::FindLastVisit: 11229 nsNavHistory::AddVisitChain(nsIURI*, long long, int, int, nsIURI*, long long*, long long*, long long*) 118185 0 11229 nsNavHistory::FindLastVisit(nsIURI*, long long*, long long*) 11223 mozStorageStatement::ExecuteStep(int*) 4 mozStorageStatement::Reset() 2 BindStatementURI(mozIStorageStatement*, int, nsIURI*)

who should own?

I guess it's my problem.

Do we still see this with Modern Places?

*ping* btw, this still got blocking1.9a1+ ...

Thanks for bringing this back up. I don't think this blocks, as we haven't had complaints of this since we overhauled the expiration mechanism. That said, the travails in bug 425987 show that this in fact does occur. The places.sqlite file on that box had over a million visits, and things certainly slowed down. If a user accumulated a large number of visits within our expiration window, they'd experience reduced performance.

Firefox/trunk has gradually become slower for me, up to the point where it recently became unusable, with minutes-long hangs that froze up the window manager. Creating a new profile seems to have solved the problem. Is it this bug that has hit me?

(In reply to comment #10) > Firefox/trunk has gradually become slower for me, up to the point where it > recently became unusable, with minutes-long hangs that froze up the window > manager. Creating a new profile seems to have solved the problem. Is it this > bug that has hit me? what OS? what FF version? on Linux it could be related to urlclassifier updates. How big is your places.sqlite file? Do you have many bookmarks? did you changed the history preferences?

(In reply to comment #11) > (In reply to comment #10) > what OS? what FF version? on Linux it could be related to urlclassifier > updates. How big is your places.sqlite file? Do you have many bookmarks? did > you changed the history preferences? > OS: Linux x86_64. The latest version I have tried that had these problems was Trunk 2008-04-28. My places.sqlite file is 4 MB. The size of bookmarks.html is 188 KB. I have not changed my history preferences recently. However, Trunk 2008-05-12 actually seems to have solved my problem. So maybe it was bug 430530 (Excess disk IO when updating the url-classifier) I was seeing.

Seems to be WFM on trunk, not marking.

Ah, this seems to be the bug that I'm suffering from. In my testing, I'm basically reloading a page (with a different has value every time) every few seconds. Every time, the content of the page is different. I'm pretty sure, this was a problem for me, until a few weeks ago. Then I discovered that disabling my browser cache 'solved' the problem for me.

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

this bug looks like resolving in "LAZY_ADD with sync statements is slow", so, add visits in background please.

Martijn, can you express why you think this needs to be a release blocker, or if you're looking for this as a potential fix for a minor 1.9.2 update?

(In reply to comment #17) > Martijn, can you express why you think this needs to be a release blocker, or > if you're looking for this as a potential fix for a minor 1.9.2 update? btw, we can't make this a fix for a minor update in any case, it involves too many and risky changes in the full way visits are handled.

Oh, sorry, I used the wrong flags.

Doesn't seem to be an issue for a lot of people, maybe I'm misreading though, so I don't think this is a blocker.

I'd say with async visits this bug is dead. Adding visits could still be expensive, but the only remaining alternative is not adding them, that is a no-option. Async visits (bug 556400) are also now skipping lazy add, so the lazy messages don't accumulate anymore.