Grand Central Dispatch vs ThreadPool Performance on Xamarin iOS

Question

I looked at the documentation for Xamarin and recommends using ThreadPool for multi-threaded functions, as can be seen here:

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

However, a test was conducted showing that Grand Central Dispatch is much more effective than ThreadPool

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

So my question is: why does Hamarin recommend ThreadPool over Grand Central Dispatch? Is Xamarin ultimately binding ThreadPool to Grand Central Dispatch? When can I choose one by one? Because if ThreadPool is optimized by Xamarin and ultimately surpasses Grand Central Dispatch, then I don't 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 streams.

Like my comment on this post you linked says (since February 2012), as well as the first paragraph in the article you linked explains the reason.

The difference between GCD and ThreadPool is that ThreadPool in Mono has a "slow start" setting so that it does not create more threads than necessary in the presence of work peaks. You can easily starve off the processor by starting too many threads, so threadpool throttles itself after creating the initial threads, and then tries to create only a new thread every second (give or take, I do not remember the actual data).

If you want to force ThreadPool to actually deploy many threads, you can control this with ThreadPool.SetMinThreads.

The reason for using ThreadPool is that the same code will work on all platforms.

Note that the document talks about using ThreadPool on top of other standard .NET APIs for streaming and says nothing about using GCD or not. It is just that threadpool is a better choice than using Threads' own control.

So the API, these days, I recommend that people use a parallel task library (TPL), which represents a much higher level of understanding of your background operations than a thread. In addition, you get the same API through the platform with the flexibility of using either the built-in stream or sending to the GCD by switching a single line of code.

Answer 2

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

The xamarin debugger gets scored in just 10 simultaneous tasks. In the release, this is not much better.

In my case, the same code on windows is superior to Mac 10x or more (note that I am not using any particular system). I tried different combinations of thread pool, asynchronous methods and asynchronous callbacks (BeginRead, etc.) - all Xamarin packages.

If I have to guess, this is due to their obsession when iOS is essentially single-threaded. Regarding their recommendations, I also assume that this is the only part of the structure that works in multithreading.

I spent weeks trying to optimize my code, but you cannot do anything, if you use multithreading, you are a stack.