View source for 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.
** Prioritize the preferences with 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 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?

== 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.
{| class="wikitable"
|-
! Preference Name!! Gist URL
|-
| network.buffer.cache.size || https://gist.github.com/0ffacfb61ce17a730df6cb2f18fa1483
|-
| network.http.spdy.chunk-size || https://gist.github.com/0ef99bb241f8de7392b592c34a605b3b
|-
| javascript.options.baselinejit.threshold || https://gist.github.com/6b2ffc3dfcdab7872c11116c79a7ad0e
|-
| javascript.options.ion.threshold || https://gist.github.com/ddf16cb123c5296cf3ca4a69a2ba6cf8
|-
| network.predictor.preconnect-min-confidence || https://gist.github.com/72dae79449b55d14e1e3a5dc67121a7f
|-
| layout.display-list.retain || https://gist.github.com/cfafaa3b88f3e0ce55dc091e3ac5190d
|-
| network.tcp.sendbuffer || https://gist.github.com/c89ed6ea370df9b67371966ff5c52a41
|-
| network.http.speculative-parallel-limit || https://gist.github.com/18f72b4c30ec552cdb7cf17cce8febaa
|-
| layers.tile-width || https://gist.github.com/6e283306aad2113c8196b5d57201ba18
|-
| network.http.spdy.default-concurrent || https://gist.github.com/4118e79b7a7ce3982747912913323130
|-
| dom.idle_period.throttled_length || https://gist.github.com/f2d0285587888c42a36bdecda967c4ee
|-
| layers.tile-height || https://gist.github.com/4e82e980238c740e4e9dd41e729c0e9f
|-
| network.http.max-persistent-connections-per-server || https://gist.github.com/8994e522a9eb6dc4f7fe1c79320bd215
|-
| network.buffer.cache.count || https://gist.github.com/7c8b2ca0d987f0ed6897695c35a55095
|}

* 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.

== External Links ==