Question

我们有一个带有Parallel.For循环的C＃（.NET 4.0框架）项目，在Visual Studio内的自动化测试中运行速度很快，但是相同的并行化代码在独立应用程序中没有按预期运行，我们正试图找出原因。

代码是高内存使用率，但我们的工作站（Windows 7 PC）有足够的RAM，所以我不期望任何内存分页问题。并行化循环中没有文件I / O或GUI代码。

在独立版本中，代码在多个线程和内核上运行，但似乎被限制为不超过总共1个CPU的CPU时间，尽管分支到多个内核。因此，如果代码按顺序使用100％的1个CPU，则看起来它将使用超过4个CPU的25％。

从Visual Studio内部运行代码的自动化测试没有此限制。控制台应用程序显示为受限制，而自动测试则没有。

我在每个设置之间比较了Thread和ProcessThread设置，它们似乎是等效的。它们使用相同的SynchronizationContext（null）和TaskScheduler（默认值）。

我还尝试用手动创建的Parallel.For替换Thread，而且似乎没有改变任何内容。

我应该寻找什么可能导致Visual Studio中的自动化测试与独立应用程序之间出现这种差异？

以下是一些相关的示例代码：

public void Process(string name)
{
    //...

    Results bestResult = null;
    int best = int.MaxValue;
    Object lockObject = new Object();

    var parent = new Data(this.nameToPart[name]);
    var myParams = new Params(this.params);

    Parallel.For(0, myParams.numRunsPerLvl, (i) =>
    {
        var result = Processor.MultilevelProcessor(parent, myParams);

        if (part.cost < bestCut)
        {
            lock (lockObject)
            {
                if (part.cost < best)
                {
                    best = part.cost;
                    bestResult = result;
                }
            }
        }
    });

    //...
}

Answer 1

也许TaskScheduler与众不同？尝试检查 System.Threading.Tasks.TaskScheduler.Current 属性（在任务上下文中）。

Answer 2

我终于找到了解决问题的方法。设置gcServer设置为true的App.config文件解决了我们的问题。我们的应用程序如此实例化，以至于垃圾收集器正在破坏性能。我想Visual Studio在运行单元测试时会以不同的方式运行垃圾收集器吗？在未来，我们还将努力减少GC的使用。

当并行化代码在Visual Studio自动化测试中运行得更快时，该寻找什么？

2 个答案: