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). -Nathan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
