http://www.pctipsbox.com/simple-firefox-speed-tweak/
Recommends setting network.prefetch-next to false.
Is this a good idea?
http://www.lifehack.org/articles/lifehack/up-to-date-tips-increasing-firefox-performance.html
Recommends http.pipelining (yikes!), nglayout.initialpaint.delay=0, and
adding /Prefetch:1 to end of the launching script
Anyone up for taking a pass through the default configs to see if there
are any settings that should be tweaked?
Best,
Schrep
> http://www.pctipsbox.com/simple-firefox-speed-tweak/
>
> 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.
> http://www.lifehack.org/articles/lifehack/up-to-date-tips-increasing-firefox-performance.html
>
>
> Recommends http.pipelining (yikes!)
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
Hmm, never heard of this.
Ah, MSDN suggests this is totally bogus:
http://blogs.msdn.com/ryanmy/archive/2005/05/25/421882.aspx
Justin
>> adding /Prefetch:1 to end of the launching script
>
> Hmm, never heard of this.
>
> Ah, MSDN suggests this is totally bogus:
>
> http://blogs.msdn.com/ryanmy/archive/2005/05/25/421882.aspx
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.
Phil Ringnalda
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.
- Vlad
Justin Dolske wrote:
> Mike Schroepfer wrote:
>
>
>
>> http://www.lifehack.org/articles/lifehack/up-to-date-tips-increasing-firefox-performance.html
>>
>>
>> Recommends http.pipelining (yikes!)
>>
>
> 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.
indvidual bugs like this one need to be tested more and figured out.
https://bugzilla.mozilla.org/show_bug.cgi?id=334043
also bugs with [pipelining] in the status whiteboard
and title like this query need to be looked at investigated more
https://bugzilla.mozilla.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=exact&emailtype2=exact&field-1-0-0=resolution&field-1-1-0=short_desc&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=substring&query_format=advanced&remaction=&resolution=DUPLICATE&resolution=---&short_desc=pipelining&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=allwordssubstr&type0-0-0=noop&value-1-0-0=DUPLICATE%2C---&value-1-1-0=pipelining&value0-0-0=&votes=&order=bugs.bug_id&query_based_on=
-chofmann*
*
lots of early research and tuning went in to the setting we have now
dating back to http://weblogs.mozillazine.org/dave/archives/2002_04.html
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....
a dynamic system would be a lot more work.
-chofmann
> 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.
I've filed bug 395838 -- Remove HTTP pipelining pref from release builds.
Justin
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.
Peter.