Remove fretboard to improve startup performance #5182
Comments
|
@csadilek or @colintheshots Can you add the eng:performance label to this? Thank you! |
mcomella
moved this from Needs prioritization
to Backlog (prioritized)
in Performance, front-end roadmap
colintheshots
moved this from Backlog (prioritized)
to In progress
in Performance, front-end roadmap
|
I was looking at fixing this by removing Fretboard in favor of our new services-experiements framework to do less work. However, I believe the new services-experiments A-C code is not ready. As written, the new library code appears to statically load only a single experiment at one time within the call to Instead, I could maybe look at using Fretboard exclusively until the new library is fixed. As for migrating work to a background thread, I need to be sure experiments have reasonable defaults if experiments have not yet been loaded. |
|
At a minimum, we should probably remove Fretboard. FxA is the last consumer and it's no longer being used to host any experiments. |
…ve Fretboard This removes Fretboard. The goal is to reduce cold startup costs associated with loading the experiments on the main thread. We currently have two experiments frameworks in use and should only require one.
…ve Fretboard This removes Fretboard. The goal is to reduce cold startup costs associated with loading the experiments on the main thread. We currently have two experiments frameworks in use and should only require one.
…ve Fretboard This removes Fretboard. The goal is to reduce cold startup costs associated with loading the experiments on the main thread. We currently have two experiments frameworks in use and should only require one.
…ve Fretboard This removes Fretboard. The goal is to reduce cold startup costs associated with loading the experiments on the main thread. We currently have two experiments frameworks in use and should only require one.
…ve Fretboard This removes Fretboard. The goal is to reduce cold startup costs associated with loading the experiments on the main thread. We currently have two experiments frameworks in use and should only require one.
…ve Fretboard This removes Fretboard. The goal is to reduce cold startup costs associated with loading the experiments on the main thread. We currently have two experiments frameworks in use and should only require one.
|
@colintheshots Are there any next steps here or can this be closed? |
|
Fretboard was removed. We should file a new issue if |
mcomella
changed the title
|
Addressed in #7510. |
|
@baron-severin Would you mind writing a QA note for this issue? I assume we should at least test that the FxA features are enabled/disabled properly. tbh, I'm a little confused about the phrasing of the landed code – |
Note to whoever from QA picks this up, would you mind verifying that there have been no regressions in App Services web channels, login sync, and pairing? No need to verify performance, the perf team is handling that.
Agreed that the names are a bit misleading, but I'm less concerned about bugs there as the properties were moved from an existing file ( |
|
Done some testing around signup, login, sync and pairing and haven't noticed anything suspicious. I'll mark this as verified. |
sv-ohorvath
added
eng:qa:verified
ExperimentsInternalAPI.initializeandFenixApplication.loadExperimentsare called from within theFenixApplication.SetupApplicationfunction.SetupApplicationtakes 290ms and the two experiment-related functions take 45ms (approximately 15%).There are also StrictMode violations that come from loading experiments on the main thread.
It would appear that we have regressed somehow from #1616 where we moved experiment loading off the main thread. I'm not sure if this was intentional, but we need to look at it.
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: