[Mono-dev] High CPU usage in System.Thread.Sleep on OS X after v. 4.3.2

Emil Sandstø emil at fusetools.com
Thu Sep 8 14:16:01 UTC 2016

There has been a CPU performance regression in between the release of 4.3.2
and 4.4.0, on OS X when using System.Threading.Sleep. It's pretty critical,
we are talking about order of magnitude difference in performance between
those versions. Also it has been reproduced on more than one machine that
runs either El Capitan or Sierra, but not tested on earlier OS X versions.

I have made a code snippet that triggers the regression:
It creates a thread that sleeps for one millisecond continuously in a loop.

# Profile data
When running the test in version 4.4.0 or higher the CPU usage is around 60
% of a core on my machine. However when running 4.3.2 or earlier versions,
the CPU usage is around 2-3 % of a core, which is as expected. Furthermore,
I've found that the bottleneck is pretty deep in Mono.

This is profile data from running 4.3.2:

And this is profile data from running 4.4.0:

What I'm find interesting is how much more time which is spent in
'pthread_cond_wait' in version 4.4.0 than in 4.3.2.
To be more specific, in 4.4.0 'pthread_cond_wait' calls __gettimeofday
which is where most of the CPU time is used.
And in 4.3.2 that internal method in pthread_cond_wait isn't called at all.

# Steps to reproduce
1. Download and install
2. Build and run my test code (
3. Take a note of the "average" CPU usage.

4. Download and install http://download.mono-project.com/archive/4.4.0/ or
a later version (same issue on 4.6.0 as well)
5. Build and run my test code (
6. Take a note of the "average" CPU usage and compare to what you found in

I would like someone with more knowledge of the mono codebase to take a
look at this issue. I'm also available to test patches in our production
codebase, for end-to-end testing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20160908/213f92b4/attachment.html>

More information about the Mono-devel-list mailing list