On 31/03/2016 07:42, Kyle Huey wrote: > I'll pose to you the same question I posed bsmedberg, is this actually > worth fiddling with all the existing runnables.
I did some testing around a couple of years ago and the answer is the same as usual: it depends. On modern x86 machines I doubt one would be able to measure the difference; sure it's there, but it's small enough that it's generally not worth the fuss. On entry-level ARM stuff (Cortex A5, A7, etc...) it's definitely there, but mostly because using nsIRunnable requires atomics for ref-counting which are very expensive on those cores. So there's definitely a cost over stuffing a raw (function) pointer into an array and calling it later. So it comes down to a cost/benefit tradeoff. On the one hand it would be nice to have a lighter alternative to nsIRunnable provided it doesn't require massive changes in the code, on the other hand its impact would be limited on the vast majority of our users. 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. Gabriele
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
