Skip to content
This repository has been archived by the owner on Feb 20, 2023. It is now read-only.

Reimplement clock_ticks_per_second as quantity #18157

Closed
mcomella opened this issue Feb 24, 2021 · 1 comment
Closed

Reimplement clock_ticks_per_second as quantity #18157

mcomella opened this issue Feb 24, 2021 · 1 comment
Assignees
Labels
performance Possible performance wins

Comments

@mcomella
Copy link
Contributor

mcomella commented Feb 24, 2021

clock_ticks_per_second is implemented as a counter. This means:

  • GLAM displays the data in a format that is not useful to answer our query (what are all the values users have and what's the distribution of those values?)
  • it may be implemented correctly if the ping is submitted at the right time but it's more error-prone because we may accidentally sum the values together

The easiest thing to do is to convert this to a counter. It may be good to rename it as part of this work to avoid confusion later.

┆Issue is synchronized with this Jira Task

@mcomella mcomella created this issue from a note in Performance, front-end roadmap (In progress) Feb 24, 2021
@mcomella mcomella added the performance Possible performance wins label Feb 24, 2021
@mcomella mcomella self-assigned this Feb 24, 2021
@github-actions github-actions bot added the needs:triage Issue needs triage label Feb 24, 2021
mcomella added a commit to mcomella/fenix that referenced this issue Feb 24, 2021
…type.

While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
mcomella added a commit to mcomella/fenix that referenced this issue Feb 24, 2021
…type.

While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
mcomella added a commit to mcomella/fenix that referenced this issue Feb 24, 2021
…type.

While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
mcomella added a commit to mcomella/fenix that referenced this issue Feb 24, 2021
…type.

While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
mcomella added a commit that referenced this issue Feb 27, 2021
While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
@amedyne amedyne removed the needs:triage Issue needs triage label Feb 27, 2021
@mcomella
Copy link
Contributor Author

mcomella commented Mar 1, 2021

Landed with f44611f

@mcomella mcomella closed this as completed Mar 1, 2021
Performance, front-end roadmap automation moved this from In progress to Done Mar 1, 2021
pkirakosyan pushed a commit to gexsi/user-agent-android that referenced this issue Aug 4, 2021
…type.

While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
performance Possible performance wins
Development

No branches or pull requests

2 participants