On Thu, Mar 31, 2016 at 6:43 AM, Nathan Froyd <nfr...@mozilla.com> wrote:
> On Thu, Mar 31, 2016 at 8:08 AM, Gabriele Svelto <gsve...@mozilla.com> > wrote: > > On this topic, did anyone experiment with trying to lighten the > > synchronization burden when handling nsEventQueues? Both nsThread and > > nsThreadPool acquire a mutex each time we need to get the next runnable; > > we could pull out all pending runnables every time we acquire the lock > > (up to a predefined maximum) to amortize the synchronization cost. In my > > measurements mutex-handling was also quite expensive on low-end ARM > > cores, not so much on x86 as long as the mutex was not contended. > > There was some optimization work done in bug 1195767 and bug 1202497 > to reduce the amount of locking we do for both nsThreadPool and > nsThread, respectively, and to use signaling on internal condition > variables rather than broadcast. I know the changes were significant > in the case of nsThreadPool on some platforms; in the nsThread case we > are obviously doing less work, but I didn't try to measure the > savings. I don't think we've experimented with trying to pull out > multiple events per lock acquisition (which sounds pretty tricky to do > such that you're actually saving work). That sounds very difficult to do if the event loop gets spun. - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
