如何提高 WPF 中后台任务的性能？

Question

我正在构建一个 WPF 应用程序，它将在后台执行一些繁重的工作。问题是当我在单元测试中运行任务时，通常需要大约 6~7 秒才能运行。但是当我在 WPF 应用程序中使用 TPL 运行它时，它需要 12 秒到 30 秒才能运行。有没有办法加快这件事。我正在调用 LogParser 的 COM api 来完成真正的工作。

更新： 我调用 Log Parser API 的代码如下所示

var thread = new Thread(() =>
            {
                var logQuery = new LogQueryClassClass();
                var inputFormat = new COMEventLogInputContextClassClass
                {
                    direction = "FW",
                    fullText = true,
                    resolveSIDs = false,
                    formatMessage = true,
                    formatMsg = true,
                    msgErrorMode = "MSG",
                    fullEventCode = false,
                    stringsSep = "|",
                    iCheckpoint = string.Empty,
                    binaryFormat = "HEX"
                };
                try
                {
                    Debug.AutoFlush = true;
                    var watch = Stopwatch.StartNew();
                    var recordset = logQuery.Execute(query, inputFormat);
                    watch.Stop();

                    watch = Stopwatch.StartNew();
                    while (!recordset.atEnd())
                    {
                        var record = recordset.getRecord();
                        recordProcessor(record);
                        recordset.moveNext();
                    }
                    recordset.close();
                    watch.Stop();
                }
                catch
                {
                }
                finally
                {
                    if (logQuery != null)
                    {
                        Marshal.ReleaseComObject(logQuery);
                        GC.SuppressFinalize(logQuery);
                        logQuery = null;
                    }
                }
            });
        thread.SetApartmentState(ApartmentState.STA);
        thread.Start();
        thread.Join();

现在的事情是有了这个改变，我可以看到调试模式大约有 3 - 4 秒的改进，但当我按下 Ctrl + F5 来运行它时却没有，这超出了我的想象。怎么来的？？

Answer 1

这里的问题是您使用的 COM 对象只能在 STA 线程上运行。已经有几个人提出了这个建议，但我决定检查一下，只是为了确定。我安装了 LogParser SDK，下面是它为与 MSUtil.LogQuery ProgID 关联的 CLSID 放入注册表的内容：

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}]
@="LogQuery"
"AppID"="{3040E2D1-C692-4081-91BB-75F08FEE0EF6}"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}\InprocServer32]
@="C:\\Program Files (x86)\\Log Parser 2.2\\LogParser.dll"
"ThreadingModel"="Apartment"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}\ProgID]
@="MSUtil.LogQuery.1"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}\VersionIndependentProgID]
@="MSUtil.LogQuery"

关键是"ThreadingModel"="Apartment"。这个 COM 类声明它只能在 STA 线程上运行。

TPL 和 BackgroundWorker 都使用 MTA 线程。这样做的结果是，当您从 TPL 任务或 BackgroundWorker 使用 LogParser 时，COM 运行时会检测到您在错误类型的线程上，并且会找到或创建一个 STA 来托管该对象。 （在这种特殊情况下，它将使用所谓的“主机 STA”，这是 COM 专门为此目的创建的一个线程。在某些情况下，它会使用您的主 UI 线程，但这里不是这种情况。 )

COM 然后自动将来自您的工作线程的任何调用编组到该 STA 线程。它通过 Windows 消息队列执行此操作，因此对于您执行的每个方法（请记住，属性访问器只是变相的方法，因此这也适用于属性使用），您的工作线程将向该 STA 线程发送一条消息，该 STA然后，线程的消息泵必须选择该消息并将其分派，此时 COM 运行时将为您调用 LogParser 上的方法。

如果您的 API 涉及大量调用，这会很慢。

顺便说一句，这既不是 WPF 也不是 Windows 窗体问题。这完全与使用来自非 STA 线程的基于 STA 的 COM 对象有关。如果您在其中使用非 STA 线程，您也可以使用控制台应用程序重现完全相同的问题。而且这个问题并不特定于 TPL 或 BackgroundWorker - 它会影响任何使用线程池的东西，因为线程池线程都使用 MTA，而不是 STA。

解决方案是使用 STA 线程。最好的方法是创建一个专用线程。使用 System.Threading 命名空间中的 Thread 类来启动您自己的线程。在启动它之前调用它的SetApartmentState 方法。确保从 LogParser API 创建对象实例的代码正在该线程上运行，并确保您只使用该线程中的那些对象。这应该可以解决您的性能问题。

于 2013 年 2 月 21 日编辑澄清：

请注意，仅仅确保您使用来自 STA 线程的 COM 对象是不够的。您必须使用 if 来自 您创建它的同一 STA 线程。基本上，拥有 STA 模型的全部原因是使 COM 组件能够使用单线程模型。它使他们能够假设发生在他们身上的所有事情都发生在一个线程上。如果您编写使用来自多个线程的 STA 线程的多线程 .NET 代码，它将在幕后确保 COM 对象得到它想要的，这意味着所有访问都将通过它所属的线程。

这意味着，如果您从其主 STA 线程之外的某个其他线程调用它，那么即使该其他线程也恰好是 STA 线程，您仍将支付跨线程的代价。

于 2013 年 2 月 25 日编辑添加：

（不确定这是否与此特定问题相关，但其他通过搜索登陆此问题的人很可能会感兴趣。）将工作转移到单独的工作线程的一个缺点是，如果您想更新以任何方式处理这些记录的结果，你现在在错误的线程上。如果您使用数据绑定 INotifyPropertyChanged，WPF 将自动为您处理跨线程更改通知，但这可能会对性能产生重大影响。如果您需要在后台线程上做大量工作，但该工作最终需要更新 UI，您可能需要采取措施批量更新这些更新。这并非完全无关紧要 - 请参阅从此处开始的系列博客文章：http://www.interact-sw.co.uk/iangblog/2013/02/14/wpf-async-too-fast

Answer 2

COM 为 IPC 使用消息队列。我不清楚是什么决定了 which 消息队列，但我怀疑它是 shell 消息队列，因为 Delphi 调试器和 Outlook 曾经互相玩得很开心。我未经证实的假设是，进程外的 COM 服务器可能会因 else 停止 shell 消息队列的东西而停止。 Windows 有超时来防止这种事情完全锁定系统，但它可能会导致受影响的进程大幅减速。我的解决方案是避免使用 COM。您可以通过注释掉实际使用 COM 的部分并计时该过程来检查这一点。