- Investigate the usage of current preferences:
- Understand and document existing preferences (lifetime, type, whether they are still in use, etc.)
- Clean up preferences (unused, incorrectly used, non-obvious).
- Use preferences as performance tuning knobs and investigate the performance implications of these knobs.
- Prioritize the preferences with their relevance to performance.
- Tweak the preferences and run automated tests against the values to see their performance implications.
- Kan-Ru Chen
- Cervantes Yu
- Will Wang
- WeiCheng Pan
- Shako Ho
- Walter Chen
- Askeing Yen
- Find a systematic way to manage and prioritize default preference values.
- Co-work with libpref redesign project on new persistence format of preferences.
- Find performance related preferences during the process.
- Get feedback from relevant teams.
- Initially we may target JS related preferences.
- Record the performance implications of preferences using the new persistence format.
Things to Consider
- What's the new persistence format for preferences?
- What data should a pref contain?
- Internal name, a more descriptive name, description, default value, etc.
- #include from smaller subsets in the final pref file.
- Group prefs that are relevant (sharing the same prefix) in smaller files.
- Standalone top branch indicates that the pref should be under some other branch.
- There is only 1 pref beginning with "slider": slider.snapMultiplier
- Move to browser.slider.snapMultiplier?
- camelCase, underscore_names, or dashed-names?
- Envisioning a front-end user interface that is more user-friendly than about:config?
- Makes it easier for users to tweak or experiment with the browser.
- Inline readonly prefs in code as constants?
- A Hasal trial run to test the performance effect of changing JS baseline JIT threshold values:
- Twiddling the preference has influence of performance as can be seen in the test results, but there is no consistent change among the tests.