PLINQ执行比平时更糟糕的LINQ [英] PLINQ Performs Worse Than Usual LINQ

问题描述

神奇的是，使用PLINQ没有屈服在我创建了一个小的测试案例的利益;实际上，它比平常LINQ更糟。

Amazingly, using PLINQ did not yield benefits on a small test case I created; in fact, it was even worse than usual LINQ.

下面是测试code：

    int repeatedCount = 10000000;
    private void button1_Click(object sender, EventArgs e)
    {
        var currTime = DateTime.Now;
        var strList = Enumerable.Repeat(10, repeatedCount);
        var result = strList.AsParallel().Sum();

        var currTime2 = DateTime.Now;
        textBox1.Text = (currTime2.Ticks-currTime.Ticks).ToString();

    }

    private void button2_Click(object sender, EventArgs e)
    {
        var currTime = DateTime.Now;
        var strList = Enumerable.Repeat(10, repeatedCount);
        var result = strList.Sum();

        var currTime2 = DateTime.Now;
        textBox2.Text = (currTime2.Ticks - currTime.Ticks).ToString();
    }

结果？

textbox1: 3437500
textbox2: 781250

所以，LINQ正在较短的时间比PLINQ来完成类似的操作！

So, LINQ is taking less time than PLINQ to complete a similar operation!

我是什么做错了吗？或者是有，我不知道一个扭曲？

What am I doing wrong? Or is there a twist that I don't know about?

编辑：我已经更新了我的code使用秒表，然而，相同的行为依然存在。打折JIT的效果，我实际上点击尝试了几次都按钮1 和按钮2 并没有特定的顺序。虽然我有时间可能有所不同，但定性的行为依然存在：。PLINQ的确是慢在这种情况下的

I've updated my code to use stopwatch, and yet, the same behavior persisted. To discount the effect of JIT, I actually tried a few times with clicking both button1 and button2 and in no particular order. Although the time I got might be different, but the qualitative behavior remained: PLINQ was indeed slower in this case.

推荐答案

第一：停止使用日期时间来衡量的运行时间。使用秒表来代替。测试code看起来像：

First: Stop using DateTime to measure run time. Use a Stopwatch instead. The test code would look like:

var watch = new Stopwatch();

var strList = Enumerable.Repeat(10, 10000000);

watch.Start();
var result = strList.Sum();
watch.Stop();

Console.WriteLine("Linear: {0}", watch.ElapsedMilliseconds);

watch.Reset();

watch.Start();
var parallelResult = strList.AsParallel().Sum();
watch.Stop();

Console.WriteLine("Parallel: {0}", watch.ElapsedMilliseconds);

Console.ReadKey();

二：并行运行的东西增加了开销。在这种情况下，PLINQ具有弄清楚划分的集合，以便它可以在平行安全地求和元件的最佳方式。在这之后，你需要加入从创建的各个线程的结果，并总结那些为好。这不是一个简单的任务。

Second: Running things in Parallel adds overhead. In this case, PLINQ has to figure out the best way to divide your collection so that it can Sum the elements safely in parallel. After that, you need to join the results from the various threads created and Sum those as well. This isn't a trivial task.

使用code以上我可以看到使用的SUM（）网队〜95MS电话。调用.AsParallel（）。总和（）网围绕〜185ms。

Using the code above I can see that using Sum() nets a ~95ms call. Calling .AsParallel().Sum() nets around ~185ms.

在并行处理任务仅仅是一个好主意，如果你做它收获。在这种情况下，总和是一个很简单的任务，你不使用PLINQ获得。

Doing a task in Parallel is only a good idea if you gain something by doing it. In this case, Sum is a simple enough task that you don't gain by using PLINQ.

这篇关于PLINQ执行比平时更糟糕的LINQ的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！