On Sun, May 21, 2017, at 09:29 PM, Mark Hammond wrote: > As I mentioned at the start of the thread, in one concrete example we > had code already written that we identified being janky - > http://searchfox.org/mozilla-central/rev/f55349994fdac101d121b11dac769f3f17fbec4b/toolkit/components/places/PlacesUtils.jsm#2022
Is this a scenario where we could move this intensive logic off the (parent process) main thread by fulfilling the dream of the "SQLite interface for Workers" bug[1] by using WebIDL instead of js-ctypes to let the Sqlite.jsm abstraction operate on ChromeWorkers? The only XPConnect leakage on the Sqlite.jsm API surface is mozIStorageStatementRow[2], and although it's a bit unwieldy in terms of method count, we never exposed any of the nsIXPCScriptable magic on it that we did on statements. (And thankfully SQLite.jsm neither uses or otherwise exposes the API.) It wouldn't be a trivial undertaking, but it's also not impossible either. And if Sync is chewing up a lot of main thread time both directly (processing) and indirectly (generating lots of of garbage that lengthens parent-process main-thread GC's), it may be worth considering rather than trying to optimize the time-slicing of Sync. This does, of course, assume that Sync can do meaningful work without access to XPConnect and that there aren't major gotchas in coordinating with Places' normal operation. Note: I'm talking exclusively about using the existing asynchronous Sqlite.jsm API on top of the existing async mozStorage API usage. Andrew 1: https://bugzilla.mozilla.org/show_bug.cgi?id=853438 2: https://searchfox.org/mozilla-central/source/storage/mozIStorageRow.idl subclasses https://searchfox.org/mozilla-central/source/storage/mozIStorageValueArray.idl _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
