Project Dory

Project Goals

• 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.
  • Categorize the preferences w.r.t their relevance to performance.
  • Tweak the preferences and run automated tests against the values to see their performance implications.

Participants

• Kan-Ru Chen
• Cervantes Yu
• Will Wang
• WeiCheng Pan
• Shako Ho
• Walter Chen
• Askeing Yen

Roadmap

• Find a systematic way to manage and categorize default preferences.
  • Co-work with libpref redesign project on how default preferences are populated in the system.
  • Find performance related preferences during the process.
  • Get feedback from relevant teams.
    • Initially we may target JS related preferences.
  • Find a way to record the performance implications along with other metadata for prefs.

Things to Consider

• The current pref format is likely to remain for backward compatibility, at least for user-modified prefs.
  • Given that, how do we add new semantics to prefs and also maintain backward compatibility?
    • Record the new semantics "out-of-band", like use a separate json file to record the new semantics for prefs.
• 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?

Results

• A Hasal trial run to test the performance effect of changing JS baseline JIT threshold values:
  • https://gist.github.com/ShakoHo/2e2321294d567d913eea5eaa58af60e0
  • Twiddling the preference has influence of performance as can be seen in the test results, but there is no consistent change among the tests.

The tests are conducted using default values of the prefs along with 2 extreme values in 2 directions (larger and smaller). The extra 2 values may not be semantically valid for each prefs, but we test these extreme values to see whether twiddling with the pref values makes observable differences in user interactions as tested by Hasal test framework. More (semantically valid) test values will be added if necessary.

• Test result summary
  • javascript.options.baselinejit.threshold: for most test cases that completes quickly (< 100 ms), the default value performs similarly to the other values. Setting it to 50 is likely to have a smaller variation. For test cases that take longer time (> 200 ms) Setting the pref to 50 almost outperforms the default value. The only exception is test 'test_firefox_gslide_ail_pagedown_0', but the difference is marginal (within 1 frame).
  • javascript.options.ion.threshold: for test cases that completes under 100 ms, the default value (1000) or a larger value almost always perform better than 1. For some test cases (< 100 ms), the default value performs worse than 1, but the difference is marginal: test 'test_firefox_gsearch_ail_select_search_suggestion' completes in 15 ms in average using threshold 1, which is about 1 frame faster than the default. For larger test cases that completes > 300 ms, the default is almost always better than 1, showing that the performance gain is offset by the cost of compilation, and 10000 performs slightly better than the default for gmail and Facebook. One test that is of interest is 'test_firefox_outlook_ail_composemail_0', in which using 1 for eager compilation performs significantly better then default (about 100ms in difference). This is worthy of further look.
  • dom.idle_period.throttled_length: the default (10000) value performs similarly to the other 2 test values. Some test cases are noteworthy: in 'test_firefox_gsheet_ail_clicktab_0', 65536 performs better than default. (This pref is no longer in existence now).
  • network.buffer.cache.size for most test cases, the default (32768) performs similarly with a larger value (65536). The only test case that has noteworthy difference is 'test_firefox_gsheet_ail_clicktab_0', but the difference (~ 1 frame in mean, or 40 ms in median) may not be of interest compared to test case running time (> 900 ms).
  • network.http.spdy.chunk-size: there is no noteworthy performance difference in using non-default values.
  • network.predictor.preconnect-min-confidence: there is no noteworthy performance difference in using non-default values. The only exception is test case 'test_firefox_gsheet_ail_clicktab_0'. Using different values seems to affect performance, but the change is not consistent: the results for using 70, 50 and 10 seem to show that smaller values have positive effect, but 20 and 30 don't exhibit this trend. Maybe this test case just has such highly variable results as to hide the effects.
  • layout.display-list.retain: TBD
  • network.tcp.sendbuffer: for most test cases, there is no noteworthy performance difference in using non-default values. The only exception is 'test_firefox_gsheet_ail_clicktab_0', where 65536 performs better than the default.
  • network.http.speculative-parallel-limit: for most test cases, there is no noteworthy performance difference in using non-default values. The only exception is 'test_firefox_gsheet_ail_clicktab_0', where the default value (6) performs worse than the other 2 values under test.
  • network.http.spdy.default-concurrent: for most test cases, there is no noteworthy performance difference in using non-default values. The only exception is 'test_firefox_gsheet_ail_clicktab_0', but the default value has contradictory results in mean and median compared to the other 2 tested values.
  • network.http.max-persistent-connections-per-server: for most test cases, there is no noteworthy performance difference in using non-default values. The only exception is 'test_firefox_gsheet_ail_clicktab_0', where 1 performs better than the default.
  • layers.tile-width, layers.tile-height: for most test cases, there is no noteworthy difference in using non-default values. For layers.tile-width, test case 'test_firefox_gsheet_ail_clicktab_0' has counter-intuitive results: using 256 (default) or 64 has much better performance than using 128, 512 or 768. In contrast, using different values for 'layers.tile-height' has more consistent and expected results, but the difference is marginal. Given that the results fall within a very wide range, it's hard to say that there is difference in this case.

Bugs

• Meta bug 1188411 and dependent bugs.

External Links