User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3) Steps to reproduce: I noticed that my places.sqlite file is over 71 megabytes. Since this is stored in my roaming profile this is less than ideal. Firefox seems to have kept a history of every site I've visited since installation, presumably contributing significantly to the size of this file. I do not want to delete all history as keeping some is helpful, but there seems to be no function in Firefox to automatically retain history only up to a certain number of days. However I noticed I could delete selectively from the History sidebar, as follows. 1. Press CTRL-H to open the History sidebar 2. Right-click on the "Older than 6 months" section 3. Click "Delete" Actual results: Firefox stops responding. The right-click menu stays open, displaying on top of all other windows, even when they are maximised in front of the non-responsive Firefox window. The places.sqlite-wal file in the Firefox profile folder starts increasing rapidly in size, eventually maxing out at over 5.5 gigabytes. Eventually, after approximately 45 minutes, Firefox starts responding again. History older than 6 months has been deleted. The places.sqlite-wal file has dropped back down to under 256 kilobytes. The places.sqlite file remains at 71 megabytes, but presumably could now be compacted to reduce it. Expected results: Firefox should either show a progress bar or allow you to continue working while this happens. I was patient and allowed it to continue despite Firefox having appeared to have crashed. Most users would have given up and ended the process. Alternatively this could be avoided by building in settings, turned on by default on new installations, which prevent the history growing to such a size that it causes such enormous problems when trying to trim it down.
was Firefox giving you performance issues, since you decided to remove a lot of history, or did you do just cause the file was "big"? As far as there is no performance problem, having that file size is not an issue, my places.sqlite is far bigger and I don't have any problem. That said, sure, removing lots of history is slow, we are working on that but it's still an issue.
Performance within Firefox itself was not an issue, but a large places.sqlite sat in the Roaming Profile causes a delay when logging in and out of PCs on a domain, especially over a slow link. You could say therefore that, as a result of allowing uncontrolled growth of places.sqlite, Firefox was responsible for system performance issues. Also, as you've said, Firefox itself directly experiences performance issues when trying to remove large amounts of history from its database.
you can either create a new int pref called places.history.expiration.max_pages and set it to a reasonable value lower than the current valud for places.history.expiration.transient_current_max_pages Or you can use this add-on: https://addons.mozilla.org/en-US/firefox/addon/expire-history-by-days/?src=ss
note also bug 977149 should be able to reduce the database size by about 30-40%
places.history.expiration.max_pages may work in theory, but in practice it isn't terrible helpful. Without knowing how many pages are currently being retained (as opposed to the maximum number that could be retained) it's a stab in the dark to set a new limit that will improve the situation. When thinking in terms of history the metric to limit it should be time-related. The addon you linked sounds like it would do the trick, but this is surely functionality which should be built-in rather than relying on a 3-year-old unmaintained third-party addon which is reported to cause performance issues?
the number of pages in places.history.expiration.transient_current_max_pages is the current limit, that means a db of about 80MiB. I think using half of that value in max_pages should satisfy your needs. (In reply to Ian from comment #5) > The addon you linked sounds like it would do the trick, but this is surely > functionality which should be built-in rather than relying on a 3-year-old > unmaintained third-party addon which is reported to cause performance issues? Why do you think it's unmaintained, I did it and it's still working :)
Interesting, according to the documentation the value of places.history.expiration.transient_current_max_pages is calculated on startup based on hardware specs: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration#Preferences Surely that would make the size of places.sqlite dependent on my hardware specs too, rather than necessarily 80mb? For reference, the value on my machine is 104858 - maybe the hardware test is basic enough that this is to be expected on anything above mobile/tablet spec. My apologies if the addon is still maintained! I based that on there having been no developer replies to comments since 2012 and no updates since 2011. ;) Most of the comments seem to ask why this is not built in to Firefox itself though, so I stand by the main point I was making.
(In reply to Ian from comment #7) > Interesting, according to the documentation the value of > places.history.expiration.transient_current_max_pages is calculated on > startup based on hardware specs: > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/ > Places_Expiration#Preferences It is actually only calculated based on RAM size, with an uplimit of 80MiB. on most modern systems it's likely it will be up to the limit.
I can confirm this issue. Deleting the history of one month is extremely slow (~30 seconds or more). Sometimes the titlebar says that the app is not responding. Firefox 49.0.1 (Windows 8.1, Intel Core2 Duo E6700)
This has been happening to me on Windows 10 64-bit (with plenty of free RAM). To reproduce it, use the filter "search" to show all your search engine/Youtube etc. history entries, select everything and press delete.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 734643
You need to log in before you can comment on or make changes to this bug.