Bugzilla

I ran an experiment increasing the padding around the urlbar to 10px (from 4px) to check if it had any effect.
It actually improved youtube SpeedIndex opt cold by 17%...  but not effect on warm. It is still interesting how the test is sensitive to changes of the toolbox height.

On the profiles I've noticed this so far:
1. `before` measures things like setURI, setTabTitle, updateReaderButton while `after` onSecurityStateChange, that come earlier in the navigation, while `after` reports things like `updateReaderButton`, `onSecurityStateChange`. This seems to suggest there is a shift in times, and maybe the test measurement is suffering an initial delay.
2. There is a block of telemetry markers that in the `before` profile happen around 2.4s, in the `after` profile they happen at 1.3s, so they happen much sooner. This comes from profile-after-change TelemetryControllerParent.jsm::setupTelemetry() that contains a DeferredTask base d on toolkit.telemetry.initDelay, with a default time of 60s. It also creates a new thread and seems to also cause a couple of writeAtomics. It is happening about 1s sooner in `after` and more or less that time coincides with the time where we see a paint delay. should telemetry setup time be included in this measurement?

I'll run a further experiment delaying that telemetry block and checking its effect.

I ran an experiment increasing the padding around the urlbar to 10px (from 4px) to check if it had any effect.
It actually improved youtube SpeedIndex opt cold by 17%...  but not effect on warm. It is still interesting how the test is sensitive to changes of the toolbox height.

On the profiles I've noticed this so far:
1. `before` reports things like setURI, setTabTitle,  while `after` reports updateReaderButton onSecurityStateChange, that come earlier in the navigation, while `after` reports things like `updateReaderButton`, `onSecurityStateChange`. This seems to suggest there is a shift in times, and maybe the test measurement is suffering an initial delay.
2. There is a block of telemetry markers that in the `before` profile happen around 2.4s, in the `after` profile they happen at 1.3s, so they happen much sooner. This comes from profile-after-change TelemetryControllerParent.jsm::setupTelemetry() that contains a DeferredTask base d on toolkit.telemetry.initDelay, with a default time of 60s. It also creates a new thread and seems to also cause a couple of writeAtomics. It is happening about 1s sooner in `after` and more or less that time coincides with the time where we see a paint delay. should telemetry setup time be included in this measurement?

I'll run a further experiment delaying that telemetry block and checking its effect.

I ran an experiment increasing the padding around the urlbar to 10px (from 4px) to check if it had any effect.
It actually improved youtube SpeedIndex opt cold by 17%...  but not effect on warm. It is still interesting how the test is sensitive to changes of the toolbox height.

On the profiles I've noticed this so far:
1. `before` reports things like setURI, setTabTitle, that come earlier in the navigation, while `after` reports things like `updateReaderButton`, `onSecurityStateChange`. This seems to suggest there is a shift in times, and maybe the test measurement is suffering an initial delay.
2. There is a block of telemetry markers that in the `before` profile happen around 2.4s, in the `after` profile they happen at 1.3s, so they happen much sooner. This comes from profile-after-change TelemetryControllerParent.jsm::setupTelemetry() that contains a DeferredTask base d on toolkit.telemetry.initDelay, with a default time of 60s. It also creates a new thread and seems to also cause a couple of writeAtomics. It is happening about 1s sooner in `after` and more or less that time coincides with the time where we see a paint delay. should telemetry setup time be included in this measurement?

I'll run a further experiment delaying that telemetry block and checking its effect.

I ran an experiment increasing the padding around the urlbar to 10px (from 4px) to check if it had any effect.
It actually improved youtube SpeedIndex opt cold by 17%...  but not effect on warm. It is still interesting how the test is sensitive to changes of the toolbox height.

On the profiles I've noticed this so far:
1. `before` reports things like `setURI`, `setTabTitle`, that come earlier in the navigation, while `after` reports things like `updateReaderButton`, `onSecurityStateChange`. This seems to suggest there is a shift in times, and maybe the test measurement is suffering an initial delay.
2. There is a block of telemetry markers that in the `before` profile happen around 2.4s, in the `after` profile they happen at 1.3s, so they happen much sooner. This comes from profile-after-change TelemetryControllerParent.jsm::setupTelemetry() that contains a DeferredTask base d on toolkit.telemetry.initDelay, with a default time of 60s. It also creates a new thread and seems to also cause a couple of writeAtomics. It is happening about 1s sooner in `after` and more or less that time coincides with the time where we see a paint delay. should telemetry setup time be included in this measurement?

I'll run a further experiment delaying that telemetry block and checking its effect.