【问题标题】:Poor performance of WPF application reading from Excel on separate thread在单独的线程上从 Excel 读取 WPF 应用程序的性能不佳
【发布时间】:2011-05-18 21:21:06
【问题描述】:

我的项目中有一些代码使用 Excel COM API 读取和写入 Excel 2003。现在这段代码从两个地方调用:
1. 从 Excel 加载项本身,在同一个线程上。
2. 从 WPF 应用程序,其中 WPF 窗口在单独的线程上调用。

问题是,当 WPF 应用程序调用代码时,从 Excel 读取应该需要 10 秒的正常操作需要 2 分钟。我认为这是因为来自新线程的调用,但我不是 100% 确定。

有什么想法吗?

【问题讨论】:

  • 我认为 10 秒目标是基于 Excel 中运行的代码? WPF COM 调用可能必须启动 Excel 进程。您是否尝试过已经运行的进程?
  • 你是对的。 10 秒目标基于 Excel 中的代码。但即使通过 WPF,Excel 也始终处于打开状态,并且在该实例上调用代码。 Excel COM API 在活动实例上工作,因为我们不需要在任何地方提供 Excel 文件的名称。
  • 当时我唯一可以建议的就是两个进程之间存在闲聊。所有数据都需要跨流程边界进行编组,并从托管到非托管进行编组。喋喋不休会加剧这种情况。如果不是很健谈,那么我不确定性能问题出在哪里。

标签: wpf multithreading performance excel


【解决方案1】:

你有很多事情需要考虑:

  • COM API 可能会启动 Excel 进程。启动该过程并等待它准备好需要时间。
  • 可能跨越了进程边界,这比进程内的东西要慢。
  • 您可能陷入了在代码中创建的 COM 对象的线程关联性陷阱。它们可能与创建它们的线程有关联,这意味着即使您在另一个线程上使用 COM 对象,该代码的实际运行也会被编组回对象的拥有线程。但是,这应该很明显,因为如果代码足够密集,您的 UI 将会卡顿。

抱歉,这不是一个直接的答案,但它提供了一些值得探索的地方。

【讨论】:

  • 设法提高了相当多的性能(现在任何操作都需要 10-12 秒)。感谢您的提示。
  • @Prakash 你最终确定了确切的问题吗?这是我提到的要点之一吗?
  • 问题出在不同线程之间的通信上。我进行了更改以传递当前线程的 Dispatcher,以便所有消息都由该 Dispatcher 处理。成功了。
  • 不错,以后我也会记住的——没有考虑调度员。
猜你喜欢
  • 2011-03-30
  • 1970-01-01
  • 2019-06-14
  • 1970-01-01
  • 1970-01-01
  • 2012-09-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多