So, I was doing some testing for bug 65315 (which was a nice win for the loading of very large images no linux, courtesy of tor), and in the process of doing the tests, I created a profile on a local disk drive. Normally, I create my profiles in ~/.mozilla (the default), but of course, /u/jrgm is an NFS mount point. Anyhow, I got some times for linux that were substantially faster than I normally get due to having my profile on a local drive. Overall, the improvement was about 30%, with a range from 5% to 50% [all percentages expressed as the difference between the times for local and remote profiles, divided by time for the remote profile]. I did the equivalent test on macos9.0 and win2k (reversing the normal situation and putting my profile on my WinNT Share on rocknrool). In these tests, mac performance dropped by 65% (range 27% to 80%), and win32 performance dropped by 57% (7% to 88%). Now, of course, performance has to be degraded if you run your profile on a networked drive (cache, cookies, history, localstore, prefs being resources that are actively accessed). But, the size of the improvement was surprising (at least it was to me), and I didn't feel that I should just drop this tidbit on the floor. But, it may be that that is just the way things have to be (i.e., "Great John. Thanks for 'discovering' that networks are slower than backplanes. Duh!" :-).

Great John. Thanks for discovering that networks are slower than backplanes! Seriously though, it would be interesting to see how much of the slowdown is each of the components. I bet the fact that the cache folder is on the remote drive is most damaging. We removed the UI to change the location of the cache folder from 6.0 due to lack of time. If we can get that back in, that will make an improvement for those that go to the trouble of changing the default. For the default case, the new cache design doesn't hit the disk for a cache miss, so I would expect to see some improvement there as well.

(And for my next trick, I will demonstrate that you can't push a rope ...) So, if I set 'browser.cache.directory' to point back again to a local drive, is this all I need to do to get a "split" profile? I wonder if a pair of quantify runs (either with or without that "split" profile) might be interesting.

I believe that's all it takes. Splits runs would be great.

I did a "split" run on win2k (two brand new profiles, one on a remote NT share with the cache pref pointing to a directory on a local hard drive, and the other profile with all contents on a local hard drive), and ran a page load timing test. There was no significant difference in the times recorded, so this slowdown is all cache related (and the slowdown has to happen, the only question being how much, and whether there are opportunities to avoid I/O as gordon notes above).

Thanks John. This is great info! Now that you've eliminated the rest of the profile as the culprit, that leaves just two issues: the cache needs to minimize the frequency with which it hits the disk, and we need UI for setting the location of the disk cache folder. I have some ideas how to address the first issue are incorporated in my proposed cache design changes, and we already have a bug on the second (bug 46490).

Cache bugs to Gordon

I'm going to mark this as a duplicate of 74085, a request to store the default cache folder on a local volume. This bug simply states the reason why we want bug 74085 fixed. *** This bug has been marked as a duplicate of 74085 ***

I can dig it, baby.