Home » excel » multithreading – Poor performance of WPF application reading from Excel on separate thread

multithreading – Poor performance of WPF application reading from Excel on separate thread

Posted by: admin May 14, 2020 Leave a comment

Questions:

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?

How to&Answers:

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.