We should totally be able to afford the very low cost of a rarely-contended lock. What's going on that causes uncached pref reads to show up so hot in profiles? Do we have a list of problematic pref keys?
On Tue, Jul 17, 2018 at 8:57 AM, Kris Maglione <kmagli...@mozilla.com> wrote: > On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan Kew wrote: >> >> On 13/07/2018 21:37, Kris Maglione wrote: >>> >>> tl;dr: A major change to the architecture preference service has just >>> landed, so please be on the lookout for regressions. >>> >>> We've been working for the last few weeks on rearchitecting the >>> preference service to work better in our current and future multi-process >>> configurations, and those changes have just landed in bug 1471025. >> >> >> Looks like a great step forward! >> >> While we're thinking about the prefs service, is there any possibility we >> could enable off-main-thread access to preferences? > > > I think the chances of that are pretty close to 0, but I'll defer to Nick. > > We definitely can't afford the locking overhead—preference look-ups already > show up in profiles without it. And even the current limited exception that > we grant Stylo while it has the main thread blocked causes problems (bug > 1474789), since it makes it impossible to update statistics for those reads, > or switch to Robin Hood hashing (which would make our hash tables much > smaller and more efficient, but requires read operations to be able to move > entries). > >> I am aware that in simple cases, this can be achieved via the >> StaticPrefsList; by defining a VARCACHE_PREF there, I can read its value >> from other threads. But this doesn't help in my use case, where I need >> another thread to be able to query an extensible set of pref names that are >> not fully known at compile time. >> >> Currently, it looks like to do this, I'll have to iterate over the >> relevant prefs branch(es) ahead of time (on the main thread) and copy all >> the entries to some other place that is then available to my worker threads. >> For my use case, at least, the other threads only need read access; >> modifying prefs could still be limited to the main thread. > > > That's probably your best option, yeah. Although I will say that those kinds > of extensible preference sets aren't great for performance or memory usage, > so switching to some other model might be better. > >> Possible? Or would the overhead of locking be too crippling? > > > The latter, I'm afraid. > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
