User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a1) Gecko/20110526 Firefox/7.0a1 Build Identifier: I have noticed that clearing a large disk cache manually, or when the browser removes the cache after a crash, my hard drive is thrashed with write outs. A 1GB cache can take between 10 to 15 minutes to clear. Browser during this time has a large performance hit, and so does the OS and any other app as they are fighting for HDD time. I believe I have found the problem is with the cache becoming scattered on the HDD. I tried the simple task of copying the cache directory to another drive, remove the original directory, and then copy back the cache directory to the original drive. Under OS X this method should make the files locations more sequentially laid out on the HDD. Copying to the second drive takes 20+ minutes. If I then remove the cache from the original drive, again very slow to removing using trash can, and then copy back again, it takes no more than a minute to copy over. If I then manually remove the cache, again it takes no longer than 30 seconds. Had a quick chat in IRC, Logan also mentioned a similar experience under Linux: "logan: firefox cache became gigantic in 4..i remember trying to rsync my homedir and it was taking like 30 minutes when it should have only taken seconds logan: i had 1024MB in 1.2 million files :S" Perhaps coming up with a method of making the cache contiguous as possible on the drive is a solution? I'm unsure if there is also a performance gain to be made with loading cache while browsing. Reproducible: Always

you may as well change the platform to all, since i am seeing the same thing on windows. It was never this slow in 3.6, and 4.0 beta.

and infact, rather than a browser performance hit, the browser is entirely unusable while the cache is clearing.

Danial, I agree. Is it still slow after Windows has run a defrag? Bug 105843 doesn't help with the problem in this bug, and I do not know if bug 473056 is one reason to why there is such a huge performance hit in Firefox. Safari and Chrome are fine when browsing the web when the cache is clearing, just a little slow at loading the app.

defrag doesn't appear to help at all, its almost like they are moving / deleting all files individually which is quite slow and process intensive. the disk resource viewer seems to support that idea as the ntfs $bitmap$ (or other ntfs file) was getting updated more than the files were getting deleted.

Any chance of narrowing down the build that the problem first appeared in for you? (Old versions including the builds that led up to the 4.0.1 release are on ftp.mozilla.org)

the problem with that is browsing enough to fill the cache to a point where it occurs, since you can't make a copy of the cache folder, and it seems more related to amount of files than the size of those files.

I think the regression started when bug 175600 was pushed. It is the amount of files, they can go in to the hundreds of thousands, and how they become scattered across the hard drive. I have had a quick look using iDefrag to verify if they are scattered, and it seems they are, the cache files are not fragmented though. Moving from one drive to another, and back to the boot drive has made them almost sequential in their location. Which explains why it it so quick to clear the cache when they have been made sequential. This really reminds me of having a fixed static virtual memory vs. dynamic one that can increase and decrease in size by itself, becoming fragmented over time and becomes very slow. Perhaps a solution might be to have a static file that is created for the cache to be stored in, should pack them closer together on my old mechanical HDD?

Just thought I'd clear my cache to see how slow it was to empty. Sat with beachball of death for 15 minutes while write outs of the hard drive were being made.

The solution we've discussed is renaming a cache directory and then deleting it on a background thread, perhaps in a throttled way. We might have to do some variation on that given certain OS restrictions, but I'll leave the exact plan to those who will be implementing it.

This sounds very much like the same problem as seen in bug #630420 except that clearing the cache in this bug is triggered by the user. Michal - do you agree?