Tinderbox performance tests and accessibility

Apparently at least some of the performance tinderboxen have accessibility 
enabled?  Or something?  See bug 357583 [1] and the Tp impact it had (probably 
by inadvertently turning off all the layout accessibility hooks):

About 6% Tp improvement on on bl-bldxp01?  (Hard to tell; few cycles)
About 15% Tp improvement on bl-bldlnx01 Dep argo-vm.
About 10% Tp2 improvement on bl-bldlnx01 Dep argo-vm.
About 16% Tp improvement on bl-bldlnx01 Dep fx-linux-tbox.
About 12% Tp2 improvement on bl-bldlnx01 Dep fx-linux-tbox.
Apparently no change on Mac.

I guess my question is whether we in fact want to be testing builds with 
accessibility active, and if so whether we also want to be testing ones where 
it's inactive (which I dearly hope is true for most of our target audience... 
though it being active on the Linux tinderboxen does not make me hopeful).

-Boris

Re: Tinderbox performance tests and accessibility

Boris Zbarsky wrote:
> Apparently at least some of the performance tinderboxen have 
> accessibility enabled?  Or something?  See bug 357583 [1] and the Tp 
> impact it had (probably by inadvertently turning off all the layout 
> accessibility hooks):

Actually, it's more likely that it's simply leaking all the documents for the 
lifetime of the app, which is faster than unloading them.

-Boris

Re: Tinderbox performance tests and accessibility

On Friday 2007-05-04 02:41 -0500, Boris Zbarsky wrote:
> I guess my question is whether we in fact want to be testing builds with 
> accessibility active, and if so whether we also want to be testing ones where 
> it's inactive (which I dearly hope is true for most of our target audience... 
> though it being active on the Linux tinderboxen does not make me hopeful).

It wouldn't surprise me if some Linux distros shipped with
accessibility support turned on, since I think some GNOME projects
use the accessibility APIs in GNOME for automated testing.

For what it's worth, I wrote a Firefox extension that adds an about
page that says whether accessibility is enabled:
https://addons.mozilla.org/en-US/firefox/addon/2407

-David

--

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-performance mailing list
dev-performance <at> lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-performance

Re: Tinderbox performance tests and accessibility

L. David Baron wrote:
> On Friday 2007-05-04 02:41 -0500, Boris Zbarsky wrote:
>> I guess my question is whether we in fact want to be testing builds with 
>> accessibility active, and if so whether we also want to be testing ones where 
>> it's inactive (which I dearly hope is true for most of our target audience... 
>> though it being active on the Linux tinderboxen does not make me hopeful).
> 
> It wouldn't surprise me if some Linux distros shipped with
> accessibility support turned on, since I think some GNOME projects
> use the accessibility APIs in GNOME for automated testing.
> 
> For what it's worth, I wrote a Firefox extension that adds an about
> page that says whether accessibility is enabled:
> https://addons.mozilla.org/en-US/firefox/addon/2407
> 
> -David

I have to say, this is the most amusing add-on I have seen.

Given that there are about 100-ish configuration options that affect how 
Firefox was built and runs, and many, many environment variables that 
affect things, how did you come to create an extension just for this one 
option?

- ray

Re: Tinderbox performance tests and accessibility

On Friday 2007-05-04 15:04 -0700, Ray Kiddy wrote:
> L. David Baron wrote:
> > For what it's worth, I wrote a Firefox extension that adds an about
> > page that says whether accessibility is enabled:
> > https://addons.mozilla.org/en-US/firefox/addon/2407

> I have to say, this is the most amusing add-on I have seen.
> 
> Given that there are about 100-ish configuration options that affect how 
> Firefox was built and runs, and many, many environment variables that 
> affect things, how did you come to create an extension just for this one 
> option?

Because whether it is enabled (in a build in which it was compiled)
is determined dynamically at runtime, and we don't expose any
mechanism for a user to determine what that runtime decision was.
Since I needed to determine that to debug a problem, I made a way to
find out what that decision was.

-David

--

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-performance mailing list
dev-performance <at> lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-performance