39

Here is the code:

using (var context = new AventureWorksDataContext())
{
    IEnumerable<Customer> _customerQuery = from c in context.Customers
                                           where c.FirstName.StartsWith("A")
                                           select c;

    var watch = new Stopwatch();
    watch.Start();

    var result = Parallel.ForEach(_customerQuery, c => Console.WriteLine(c.FirstName));

    watch.Stop();
    Debug.WriteLine(watch.ElapsedMilliseconds);

    watch = new Stopwatch();
    watch.Start();

    foreach (var customer in _customerQuery)
    {
        Console.WriteLine(customer.FirstName);
    }

    watch.Stop();
    Debug.WriteLine(watch.ElapsedMilliseconds);
}

The problem is, Parallel.ForEach takes about 400ms vs a regular foreach, which takes about 40ms. What exactly am I doing wrong and why doesn't this work as I expect it to?

Theodor Zoulias
  • 34,835
  • 7
  • 69
  • 104
Mike Diaz
  • 2,045
  • 4
  • 32
  • 55
  • 11
    Basically because there's a setup cost involved, and you're not doing enough work inside the loop to justify the overhead. See e.g. [this answer](http://stackoverflow.com/questions/2828429/what-are-the-guidelines-for-parallel-foreach-vs-foreach/2828486#2828486). (I expect this is a duplicate question.) – Rup May 17 '11 at 19:35
  • 2
    The `Console.WriteLine()` makes it totally irrelevant. – H H May 17 '11 at 20:36
  • Try to remove the `Console.WriteLine()` and replace it with `c.FirstName = c.FirstName.ToLowerInvariant()`. You will not see a difference if your collection has around 5000 items; but if your collection has 6000, 7000,... 10.000 items, on a 4 cores processor, you will see a big difference (`Parallel.Foreach` will be faster) – Junior Mayhé May 14 '12 at 11:43

6 Answers6

198

Suppose you have a task to perform. Let's say you're a math teacher and you have twenty papers to grade. It takes you two minutes to grade a paper, so it's going to take you about forty minutes.

Now let's suppose that you decide to hire some assistants to help you grade papers. It takes you an hour to locate four assistants. You each take four papers and you are all done in eight minutes. You've traded 40 minutes of work for 68 total minutes of work including the extra hour to find the assistants, so this isn't a savings. The overhead of finding the assistants is larger than the cost of doing the work yourself.

Now suppose you have twenty thousand papers to grade, so it is going to take you about 40000 minutes. Now if you spend an hour finding assistants, that's a win. You each take 4000 papers and are done in a total of 8060 minutes instead of 40000 minutes, a savings of almost a factor of 5. The overhead of finding the assistants is basically irrelevant.

Parallelization is not free. The cost of splitting up work amongst different threads needs to be tiny compared to the amount of work done per thread.

Further reading:

Amdahl's law

Gives the theoretical speedup in latency of the execution of a task at fixed workload, that can be expected of a system whose resources are improved.

Gustafson's law

Gives the theoretical speedup in latency of the execution of a task at fixed execution time, that can be expected of a system whose resources are improved.

Theodor Zoulias
  • 34,835
  • 7
  • 69
  • 104
Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
12

The first thing you should realize is that not all parallelism is beneficial. There is an amount of overhead to parallelism, and this overhead may or may not be significant depending on the complexity what is being parallelized. Since the work in your parallel function is very small, the overhead of the management the parallelism has to do becomes significant, thus slowing down the overall work.

skaz
  • 21,962
  • 20
  • 69
  • 98
10

The additional overhead of creating all the threads for your enumerable VS just executing the numerable is more than likely the cause for the slowdown. Parallel.ForEach is not a blanket performance increasing move; it needs to be weighed whether or not the operation that is to be completed for each element is likely to block.

For example, if you were to make a web request or something instead of simply writing to the console, the parallel version might be faster. As it is, simply writing to the console is a very fast operation, so the overhead of creating the threads and starting them is going to be slower.

Tejs
  • 40,736
  • 10
  • 68
  • 86
6

As previous writer has said there are some overhead associated with Parallel.ForEach, but that is not why you can't see your performance improvement. Console.WriteLine is a synchronous operation, so only one thread is working at a time. Try changing the body to something non-blocking and you will see the performance increase (as long as the amount of work in the body is big enough to outweight the overhead).

salomons
  • 199
  • 5
  • 10
1

I like salomons answer and would like to add that you also have additional overhead of

  1. Allocating delegates.
  2. Calling through them.
Yola
  • 18,496
  • 11
  • 65
  • 106
0

You can as well use a Partitioner so you break the task in sized partitions to avoid the overhead from the many tasks creation.

How to: Speed Up Small Loop Bodies

Tweaking the third parameter of Partitioner.Create to decide the size of your partitions may help you in attaining better performance. In my case, I tried setting it to 2 partitions (partitions size = (total elements / 2) + 1) and achieved a slightly better performance (10% better) than with a foreach loop for a simple task.

Bear in mind that for very simple tasks, like in your case, this may not help much and your performance may be lower than using a simple foreach as prior anwers pointed out why.

Dario - Metalcam
  • 1