Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Yet another tweak Firefox perf recommendation

39 views
Skip to first unread message

Mike Schroepfer

unread,
Sep 10, 2007, 6:48:26 PM9/10/07
to
Hey Folks,

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

Justin Dolske

unread,
Sep 10, 2007, 7:47:53 PM9/10/07
to
Mike Schroepfer wrote:

> 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

Phil Ringnalda

unread,
Sep 11, 2007, 12:09:06 AM9/11/07
to
Justin Dolske wrote:
> Mike Schroepfer wrote:

>> 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

Vladimir Vukicevic

unread,
Sep 11, 2007, 4:27:25 PM9/11/07
to Mike Schroepfer
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.

- Vlad

Message has been deleted

Chris Hofmann

unread,
Sep 11, 2007, 8:08:13 PM9/11/07
to Justin Dolske, dev-per...@lists.mozilla.org

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*
*

Chris Hofmann

unread,
Sep 11, 2007, 8:26:31 PM9/11/07
to Vladimir Vukicevic, dev-per...@lists.mozilla.org

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


Justin Dolske

unread,
Sep 11, 2007, 9:32:28 PM9/11/07
to
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.

I've filed bug 395838 -- Remove HTTP pipelining pref from release builds.

Justin

Peter Weilbacher

unread,
Sep 13, 2007, 4:26:00 AM9/13/07
to

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.

0 new messages