> Recommends setting network.prefetch-next to false.
> Is this a good idea?
I believe prefetching is only done when a page explicitly requests it (and that its use is fairly uncommon), so it seems unlikely that it should have any effect most of the time.
Ugh. Has there been any discussion of disabling this pref? IIRC, it was recently decided that there were still enough problems with it (and negligible perf gains?) such that it should remain off for FF3... With these kinds of "tweak guides" being so widespread and blindly applied, I think there's an argument to be made that having this pref does us more harm than good.
> adding /Prefetch:1 to end of the launching script
It's better than bogus: it's case-sensitive. Using /prefetch:1 would make your first startup after adding it a bit slower, and then make subsequent runs a tiny bit slower (Firefox's commandline parsing and dropping the "unrecognized commandline flag: prefetch" in the error console isn't quite free), but using /Prefetch:1, as you can see by watching your Windows/Prefetch directory, does nothing but pass an unrecognized commandline flag to Firefox.
Mike Schroepfer wrote: > nglayout.initialpaint.delay=0
This is still very much a perception thing. The paint delay default is (iirc) 250 ms; so if a page takes longer than a quarter of a second to load, nothing will be painted in that first quarter second. (If a page fully loads beforehand, it gets painted right away.) Lowering this number, or setting it to 0, usually causes an overall performance loss: we spend lots of time doing layout and repainting while we're still doing incremental reflow and the like as the page is loading. However, maybe 250ms is too high of a preset these days; 100ms might be better to strike a balance between perception and reality. I have no idea how to actually test this, though.
> Ugh. Has there been any discussion of disabling this pref? IIRC, it was > recently decided that there were still enough problems with it (and > negligible perf gains?) such that it should remain off for FF3... With > these kinds of "tweak guides" being so widespread and blindly applied, I > think there's an argument to be made that having this pref does us more > harm than good.
Some good bugzilla research should be done before pipelining goes on.
Vladimir Vukicevic wrote: > Mike Schroepfer wrote:
>> nglayout.initialpaint.delay=0
> This is still very much a perception thing. The paint delay default is > (iirc) 250 ms; so if a page takes longer than a quarter of a second to > load, nothing will be painted in that first quarter second. (If a page > fully loads beforehand, it gets painted right away.) Lowering this > number, or setting it to 0, usually causes an overall performance loss: > we spend lots of time doing layout and repainting while we're still > doing incremental reflow and the like as the page is loading. However, > maybe 250ms is too high of a preset these days; 100ms might be better to > strike a balance between perception and reality. I have no idea how to > actually test this, though.
its worth looking into this in an age when a lot more people have higher speed connections and faster pc's but to do this we should also still do a bunch of testing and evaluation on slow systems and slow networks if we are going to change the default setting. the best solution might be to make the setting more dynamic so slower systems and pc's on slow connections could get the perceptual advantage of incremental painting, and higher speed networks and systems could just blast out the content....
Chris Hofmann wrote: > Some good bugzilla research should be done before pipelining goes on.
To be clear; someone did do that and it was decided NOT to turn it on for FF3. The question I raised was if the known problems are severe enough (and performance gains small enough) that we should consider removing the ability to enable pipelining via a pref in release builds.
> Vladimir Vukicevic wrote: >> Mike Schroepfer wrote:
>>> nglayout.initialpaint.delay=0
>> This is still very much a perception thing. The paint delay default is >> (iirc) 250 ms; so if a page takes longer than a quarter of a second to >> load, nothing will be painted in that first quarter second. (If a page >> fully loads beforehand, it gets painted right away.) Lowering this >> number, or setting it to 0, usually causes an overall performance loss: >> we spend lots of time doing layout and repainting while we're still >> doing incremental reflow and the like as the page is loading. However, >> maybe 250ms is too high of a preset these days; 100ms might be better to >> strike a balance between perception and reality. I have no idea how to >> actually test this, though.
> its worth looking into this in an age when a lot more people have > higher speed connections and faster pc's but to do this we should also still do a bunch > of testing and evaluation on slow systems and slow networks if we are > going to change the default setting. the best solution might be to > make the setting more dynamic so slower systems and pc's on slow > connections could get the perceptual advantage of incremental painting, > and higher speed networks and systems could just blast out the content....
I have to say that the only pages that I visit and that are faster than 1s to download and display (even with this pref set to 0) are the ones internal to our institute. Everything else even within Germany downloads+displays much slower, typically taking several seconds to display anything. Is that so much different in the US? If not, I don't see any reason to change this setting.
