PLINQ does not improve performance

Question

I wrote LINQ to find out the frequencies of unique characters from a text file. I also converted my original result to an object using select.The final result is a list. Below is the query I used.

charNodes = inputString.GroupBy(ch => ch) .Select((ch) => new TNode(ch.Key.ToString(),ch.Count())) .ToList<TNode>(); 

I have a quad-core processor, and the above request was executed in 15 ms. But, strangely enough, it took more time when I PLINQ used the same query. Below, one took about 40 ms.

 charNodes = inputString.GroupBy(ch => ch).AsParallel .Select((ch) => new TNode(ch.Key.ToString(),ch.Count())) .ToList<TNode>(); 

Worse was the case with the following query, which took about 83 ms

 charNodes = inputString.AsParallel().GroupBy(ch => ch) .Select((ch) => new TNode(ch.Key.ToString(), ch.Count())) .ToList<TNode>(); 

What is wrong here?

Answer 1

When this question arises, the answer is always the same: PLINQ overhead is higher than profit.

This is because work items are extremely small (grouping by char or creating a new object from trivial inputs). It works much better when they are bigger.

Answer 2

It is very difficult to say what happens there, strictly based on the code you provided.

TPL uses thread pool threads. A thread pool starts with about 10 threads. If you need more threads, then the thread pool will create new ones about once per second until a new thread is needed. If your loop has led to more than 10 parallel operations, it would have to spend time creating a new thread. Correction : the number of threads required for a parallel loop takes away from the available threads in the thread pool. The thread pool tries to keep the minimum number of threads available in this pool, if it notices that the threads are taking too long, it will create new ones to compensate - which requires resources. Many parts of the framework use a thread pool, so there are all sorts of features that can be associated with a thread pool. Running a thread is quite expensive.

Another, possibly, is that if the number of iterations was more than the number of available processors, then a lot of context switching appeared. Context switching is expensive and affects the load on the processors, as well as how quickly the OS can switch between threads.

If you provide more detailed information, such as input, I can provide more detailed information in the answer.