This patch is now in trunk, thanks!
-g
On 2010-01-22, at 5:05 PM, Tom Philpot wrote:
> While investigating some performance problems in our application which uses
> the embedded Mono runtime on Mac OS X targeting 10.5 and 10.6, I noticed that
> several operations spent an extreme amount of tim
I reran the revised test case Matteo provided here:
https://bugzilla.novell.com/show_bug.cgi?id=402833
Here are the results with NO_PTHREAD_TRYLOCK defined (i.e. before)
ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe
One Thread (method1) time=00:00:00.6318450
One Thread (method2) time=00
Hi,
about an year ago I posted the following bug
https://bugzilla.novell.com/show_bug.cgi?id=402833
because we realized that the performance problem in our multi-thread
app was related to memory management:
By removing the #define line as you proposed, the performance problem
disappear and bug 40
Tom,
Looking back, apple had some issues with trylock in the 10.2/10.3 days, and
this came over for safety when we did the initial osx86 port. Its probably
safe to make this change on x86 on trunk, but I'd like some metrics if you
could.
#1, run it for a bit make sure you dont get any rando
Rodrigo,
Thanks for the input. Any of the other Mono/MacOS X folks have an opinion on
this change? I've been running our heavily multi-threaded app which embeds Mono
and haven't seen any issues. We're going to start removing this #define on our
build machine and our dev's Mono installs and see
pthread mutexes on OSX are ridiculously slow. So no matter what you do, GC
performance will be significantly worse than on linux.
But we should check if this change is ok if it does give a nice boost.
On Fri, Jan 22, 2010 at 8:05 PM, Tom Philpot wrote:
> While investigating some performance p
While investigating some performance problems in our application which uses the
embedded Mono runtime on Mac OS X targeting 10.5 and 10.6, I noticed that
several operations spent an extreme amount of time in GC_lock. That code lead
me back to gcconfig.h where NO_PTHREAD_TRYLOCK is defined. I've
