Since I have seen several people point out in this thread that there's *probably* code that excessively accesses prefs:
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 this test (or writing your own version of it): https://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_preferences_usage.js 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). Cheers, Johann On Fri, Jul 20, 2018 at 10:17 PM Kris Maglione <kmagli...@mozilla.com> wrote: > On Fri, Jul 20, 2018 at 11:53:22AM -0400, Ehsan Akhgari wrote: > >On Fri, Jul 20, 2018 at 5:00 AM, Jonathan Kew <jfkth...@gmail.com> wrote: > >> +1 to that. Our need for OMT access to prefs is only likely to grow, > IMO, > >> and we should just fix it once, so that any code (regardless of which > >> thread(s) it may eventually run on) can trivially read prefs. > >> > >> Even if that means we can't adopt Robin Hood hashing, I think the > >> trade-off would be well worthwhile. > >> > > > >While it's true that the need for reading more prefs from workers will > >continue to grow, given the number of prefs we have I think it's safe to > >say that the set of prefs that we need to access from threads beside the > >main thread will be a minority of the entire set of prefs. So one way to > >have our cake and eat it too would be to separate out the prefs that are > >meant to be accessible through a worker thread and expose them through an > >alternate thread-safe API which may be a bit more costly to call on the > >main thread, and keep the rest of the min-thread only prefs on the > existing > >non-thread-safe APIs. This won't be as elegant as having one set of APIs > >to work with, of course. > > This is what we have atomic var caches are for. They can't currently be > used > for string preferences, but that's a problem that could be solved with an > rwlock. They're also a bit difficult to use for preferences which aren't > known > at compile time, but we've generally been trying to move away from using > the > preference service for such things. > > For the sorts of preferences that are generally needed by Worker threads, > though, they should mostly just work as-is. > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
