WPF 应用程序在单独线程上从 Excel 读取的性能较差

发布于 2024-11-07 17:50:27 字数 247 浏览 0 评论 0原文

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

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

有什么想法吗?

I have some code in my project that reads from and writes into Excel 2003 using Excel COM API. Now this piece of code is called from two places:
1. From within the Excel add-in itself, on the same thread.
2. From a WPF application, where the WPF window was invoked on a separate thread.

The issue is, when the WPF application invokes the code, the normal operation of reading from Excel that should take 10 seconds is taking 2 minutes. I think it is because of the invocation from a new thread, but I'm not 100% sure.

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

┈┾☆殇 2024-11-14 17:50:27

您需要考虑很多事情:

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

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

You have a number of things to consider:

  • The COM API likely launches the Excel process. It takes time to start the process and wait for it to be ready.
  • There is likely a process boundary being crossed, this is slower than in-proc stuff.
  • You may have fallen into the trap of thread-affinity of the COM objects you create in code. They might have affinity with the thread they were created on, meaning even though you use a COM object on another thread, the actual running of that code is marshalled back to the owning thread of the object. This should be obvious, however, as your UI will stutter if the code is intensive enough.

Sorry this isn't a direct answer, but it gives some points to explore.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文