Steps to reproduce:

1. Open http://xn--u8j4d5ayd.com/q-a
2. Select a server from select dropdown
3. Wait for CPU will be settled down
4. Click Orange Button

Actual Results:
The speed is slow
in my home pc: aprrox. 60-100 Mps

Expected Results:
in my my home pc: approx. 200-300 Mps

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=df91fb44b2d4bd8cf55cb2a5360094feb2c6ca6b&tochange=4881bb77b5353c7a1509a7b7a868fc443fa9d722

I confirmed that set MOZ_DISABLE_TASKCONTROLLER=1 in OS environment variable fixed the issue in the above BAD build. (Though the environment variable has been removed in Bug 1669214)

Can you look at this?
Can you give more information about MOZ_DISABLE_TASKCONTROLLER.

(In reply to Dragana Damjanovic [:dragana] from comment #1)

Can you look at this?
Can you give more information about MOZ_DISABLE_TASKCONTROLLER.

In old builds (more than 4 months ago), it used to change the code used to schedule main thread events. In theory this can result in very subtle timing differences. It also somewhat increases the overhead for runnables (although this is only really measurables for runnables that are no-ops, up to 50 000 runnables a second is fine).

I can't personally reproduce this on any machine I own.

The site above gives me 200 Mbps, which seems reasonable for a server in Tokyo.

Using speedtest.net I get 850 Mbps, which is somewhat below my internet connection capacity, although I get similar results from Edge. Our CPU usage does seem to be slightly higher than edge, nothing in the profile to obviously link this to differences in event handling though.

Profile Speedtest nightly here: https://share.firefox.dev/3dnRAQi

Here are some profiles with a build where the env var still worked:

Profile August build without env var set: https://share.firefox.dev/3s40iqS

Profile August build with env var set: https://share.firefox.dev/3u0JGT3

Nothing in here looks interesting to me, or different, then again, I can't reproduce any difference in the numbers either. No measurable impact from the TaskController is visible.

Alice, could you use https://profiler.firefox.com/ to get a profile with the latest nightly & with the build without the env var set?
It's possible that the difference is dependent on network conditions. Thanks!

I tested the download speed twice each with tokyo server04.

Profile Latest Nightly87.0a1(20210217094559) here: https://share.firefox.dev/3dpnprY
https://share.firefox.dev/3jXOkMH

Profiles with a build where the env var still worked,

Profile August build(20200801094810) without env var set: https://share.firefox.dev/3jX8Z3v
https://share.firefox.dev/3qAlrsM

Profile August build(20200801094810) with env var set: https://share.firefox.dev/3u9VbHB
https://share.firefox.dev/3pp5ggt

Interestingly,
set accessibility.force_disabled=1 fixes the slowness in both Nightly87.0a1(20210217094559) and August build(20200801094810) without env var set.

So, I think TASKCONTROLLER and a11y seem to be racing against each other.
('ATOK Japanese IME in-sight' will activate a11y in my PC)

I can also reproduce the issue if 'Windows Narrator' is enabled without 'ATOK Japanese IME in-sight'.

Moving to accessibility based on comment 5

Hi Bas. Comment 5 seems to suggest this is related to some interaction between a11y and the new TaskController. Looking at the profile, I can't see anything obvious as to why that would be the case. Are you able to reproduce this problem if you have a11y enabled? (I guess starting Windows Narrator would be one way to do that.) Do you have any ideas where to start looking?

(In reply to James Teh [:Jamie] from comment #8)

Hi Bas. Comment 5 seems to suggest this is related to some interaction between a11y and the new TaskController. Looking at the profile, I can't see anything obvious as to why that would be the case. Are you able to reproduce this problem if you have a11y enabled? (I guess starting Windows Narrator would be one way to do that.) Do you have any ideas where to start looking?

I actually have a11y enabled in the old builds (because of the bug we fixed recently not being fixed there), it doesn't seem to cause issues with me but I can retest more explicitly looking at that.

Are you still able to reproduce?

(In reply to Gregory Pappas [:gregp] from comment #10)

Are you still able to reproduce?

No longer reproduce on 114 as well as 116.0a1.