<div dir="ltr"><div>Since I have seen several people point out in this thread that there's *probably* code that excessively accesses prefs:</div><div><br></div><div>You can easily assert the name and amount of different prefs that are read during whatever scenario you'd like to perform by adding to <br>this test (or writing your own version of it): <a href="https://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_preferences_usage.js">https://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_preferences_usage.js</a></div><div><br></div><div>It currently only runs a few basic things like opening a bunch of tabs and windows and I'd be happy to mentor/review additions that cover whatever code you are maintaining (even if you don't discover anything it's good to prevent regressions creeping up).</div><div><br></div><div>Cheers,</div><div><br></div><div>Johann<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 20, 2018 at 10:17 PM Kris Maglione <<a href="mailto:kmaglione@mozilla.com">kmaglione@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jul 20, 2018 at 11:53:22AM -0400, Ehsan Akhgari wrote:<br>
>On Fri, Jul 20, 2018 at 5:00 AM, Jonathan Kew <<a href="mailto:jfkthame@gmail.com" target="_blank">jfkthame@gmail.com</a>> wrote:<br>
>> +1 to that. Our need for OMT access to prefs is only likely to grow, IMO,<br>
>> and we should just fix it once, so that any code (regardless of which<br>
>> thread(s) it may eventually run on) can trivially read prefs.<br>
>><br>
>> Even if that means we can't adopt Robin Hood hashing, I think the<br>
>> trade-off would be well worthwhile.<br>
>><br>
><br>
>While it's true that the need for reading more prefs from workers will<br>
>continue to grow, given the number of prefs we have I think it's safe to<br>
>say that the set of prefs that we need to access from threads beside the<br>
>main thread will be a minority of the entire set of prefs.  So one way to<br>
>have our cake and eat it too would be to separate out the prefs that are<br>
>meant to be accessible through a worker thread and expose them through an<br>
>alternate thread-safe API which may be a bit more costly to call on the<br>
>main thread, and keep the rest of the min-thread only prefs on the existing<br>
>non-thread-safe APIs.  This won't be as elegant as having one set of APIs<br>
>to work with, of course.<br>
<br>
This is what we have atomic var caches are for. They can't currently be used <br>
for string preferences, but that's a problem that could be solved with an <br>
rwlock. They're also a bit difficult to use for preferences which aren't known <br>
at compile time, but we've generally been trying to move away from using the <br>
preference service for such things.<br>
<br>
For the sorts of preferences that are generally needed by Worker threads, <br>
though, they should mostly just work as-is.<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote></div>