Yet another tweak Firefox perf recommendation

[schrep-2]

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
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Justin Dolske-2]

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
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Phil Ringnalda]

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

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Vladimir Vukicevic-3]

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
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Justin Dolske-2]

Vladimir Vukicevic wrote:
> Mike Schroepfer wrote:
>> nglayout.initialpaint.delay=0
>
> This is still very much a perception thing.  [...]   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.

Perhaps Beltzner, Faaborg et al have some data here, with respect to how
users perceive delays. I know there's a rough rule of thumb about having
user interfaces give feedback within ~100-500ms to avoid appearing
non-responsive; seems like there would be research in that area
applicable here.

I'm not familiar with how painting is handled, but perhaps there's also
similar data to guide how often to repaint when the page is still
loading. For example, would doing it once at 100ms and once at 500ms
(and then as needed) allow things to be both snappy and performant?

Justin
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Chris Hofmann]

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*
*
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Chris Hofmann]

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

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


_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Justin Dolske-2]

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
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Peter Weilbacher]

Chris Hofmann wrote:

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

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.

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance