Grand Central Dispatch vs ThreadPool Performance in Xamarin iOS

Question

I've reviewed the documentation for Xamarin, and it recommends using ThreadPool for multithreaded functionality, as can be seen here:

http://docs.xamarin.com/guides/ios/application_fundamentals/threading

However, a benchmark has been done showing that Grand Central Dispatch is much more performant than ThreadPool

http://joeengalan.wordpress.com/2012/02/26/execution-differences-between-grand-central-dispatch-and-threadpool-queueuserworkitem-in-monotouch/

Therefore my question is, why does Xamarin recommend ThreadPool over Grand Central Dispatch? Is Xamarin eventually going to tie ThreadPool into Grand Central Dispatch? When would one choose one over the other? Because if ThreadPool is going to be optimized by Xamarin, and eventually outperform Grand Central Dispatch, then I do not want to use Grand Central Dispatch.

Answer 1

There is very little "extra performance" that you can squeeze out of a machine, in particular a mobile device by introducing more threads.

Like my comment on that post that you linked says (from February 2012) as well as the first paragraph on the article you linked explains the reason.

The difference between GCD and ThreadPool is that the ThreadPool in Mono has a "slow start" setup, so that it does not create more threads than necessary in the presence of work peaks. You can easily starve the CPU by launching too many threads, so the threadpool throttles itself after the initial threads have been created and then tries to only create a new thread every second (give or take, I dont remember the actual details).

If you want to force the ThreadPool to actually spin up a lot of threads, you can control that with the ThreadPool.SetMinThreads.

The reason to use the ThreadPool is that the same code will work across all platforms.

Notice that the document talks about using the ThreadPool over the other standard .NET threading APIs and does not say anything about using GCD or not. It is merely that the threadpool is a better choice than rolling your own management using Threads.

That said, API wise, these days I recommend people to use the Task Parallel Library (TPL) which is a much higher level way of thinking about your background operations than a thread. In addition, you get same API across platform with the flexibility of using either the built-in threadpool, or dispatching to GCD, by switching one line of code.

Answer 2

The current problem with mono (xamarin) thread pool is that it does not perform.

The Xamarin debugger gets chocked with as little as 10 simultaneous tasks. In release it is not much better.

In my case the same code on windows is outperforming on Mac 10x or more (note I am not using ANYTHING system specific). I tried different combinations of thread pool, async methods and asynchronous callbacks (BeginRead etc.) - Xamarin sacks at all of it.

If I have to guess it relates to their obsession with IOS being inherently single threaded. As for them recommending it , I have a guess too - that is the only part of framework that works as far as multithreading is concerned.

I spent weeks trying to optimize my code , but there is nothing you can do , if your use multithreading you are stack.