任务后台辅助角色 C#

是否有任何变化表明，在 5 秒运行的进程中，多个后台工作线程的性能比任务更好？我记得在一本书中读到，任务是为短期运行的进程而设计的。

我问的理由是这样的：

我有一个需要 5 秒才能完成的过程，并且有 4000 个进程要完成。起初我做到了：

for (int i=0; i<4000; i++) {
    Task.Factory.StartNewTask(action);
}

而且这表现很差（第一分钟后，完成了 3-4 个任务，控制台应用程序有 35 个线程）。也许这很愚蠢，但我认为线程池会处理这种情况（它会将所有操作放在队列中，当线程空闲时，它会采取操作并执行它）。

现在的第二步是手动执行 Environment.ProcessorCount 后台工作程序，以及要放置在 ConcurentQueue 中的所有操作。所以代码看起来像这样：

var workers = new List<BackgroundWorker>();
//initialize workers
workers.ForEach((bk) =>
{
    bk.DoWork += (s, e) =>
    {
        while (toDoActions.Count > 0)
        {
            Action a;
            if (toDoActions.TryDequeue(out a))
            {
                a();
            }
        } 
    }
    bk.RunWorkerAsync();
});

这表现得更好。即使我有 30 个后台工作者（与第一种情况一样多的任务），它的性能也比任务好得多。

乐：

我像这样启动任务：

    public static Task IndexFile(string file)
    {
        Action<object> indexAction = new Action<object>((f) =>
        {
            Index((string)f);
        });
        return Task.Factory.StartNew(indexAction, file);
    }

索引方法是这样的：

    private static void Index(string file)
    {
        AudioDetectionServiceReference.AudioDetectionServiceClient client = new AudioDetectionServiceReference.AudioDetectionServiceClient();
        client.IndexCompleted += (s, e) =>
            {
                if (e.Error != null)
                {
                    if (FileError != null)
                    {
                        FileError(client, 
                            new FileIndexErrorEventArgs((string)e.UserState, e.Error));
                    }
                }
                else
                {
                    if (FileIndexed != null)
                    {
                        FileIndexed(client, new FileIndexedEventArgs((string)e.UserState));
                    }
                }
            };
        using (IAudio proxy = new BassProxy())
        {
            List<int> max = new List<int>();
            if (proxy.ReadFFTData(file, out max))
            {
                while (max.Count > 0 && max.First() == 0)
                {
                    max.RemoveAt(0);
                }
                while (max.Count > 0 && max.Last() == 0)
                {
                    max.RemoveAt(max.Count - 1);
                }
                client.IndexAsync(max.ToArray(), file, file);
            }
            else
            {
                throw new CouldNotIndexException(file, "The audio proxy did not return any data for this file.");
            }
        }
    }

此方法使用 Bass.net 库从 mp3 文件中读取一些数据。然后，使用异步方法将该数据发送到 WCF 服务。创建任务的 IndexFile（字符串文件）方法在 for 循环中调用了 4000 次。这两个事件（FileIndexed）和FileError 不会被处理，因此它们永远不会被抛出。

任务性能如此差的原因是您装载了太多的小任务（4000）。请记住，CPU 也需要计划任务，因此挂载大量短期任务会导致 CPU 的额外工作负载。更多信息可以在TPL的第二段中找到：

从 .NET Framework 4 开始，TPL 是首选的编写多线程和并行代码。但是，并非所有代码都是适用于并行化;例如，如果循环仅执行每次迭代的工作量很少，或者它不会运行很多迭代，则并行化的开销可能导致代码跑得更慢。

使用后台辅助角色时，将可能的活动线程数限制为 ProcessCount。这减少了大量的调度开销。

鉴于您有一个严格定义的事情列表，我会使用 Parallel 类（For 或ForEach，具体取决于更适合您的类）。此外，您可以将配置参数传递给以下任何方法，以控制同时实际执行的任务数：

        System.Threading.Tasks.Parallel.For(0, 20000, new ParallelOptions() { MaxDegreeOfParallelism = 5 }, i =>
        {
            //do something
        });

上面的代码将执行 20000 个操作，但不会同时执行超过 5 个操作。

我怀疑后台工作线程为您做得更好的原因是您在开始时就创建和实例化了它们，而在示例Task代码中，您似乎正在为每个操作创建一个新的Task对象。

或者，您是否考虑过使用在开始时实例化的固定数量的Task对象，然后像使用后台工作线程那样使用ConcurrentQueue执行类似的操作？这也应该证明是相当有效的。

您是否考虑过使用线程池？

http://msdn.microsoft.com/en-us/library/system.threading.threadpool.aspx

如果在使用线程时性能较慢，则只能是由于线程开销（分配和销毁单个线程）造成的。

相关内容

最新更新

热门标签：