2

I have some code which interops with some COM dlls and ActiveX controls, and then fetches me some result. I am trying to run this code in the background in another thread.

But I have a problem, if I use UI thread to achieve this, the application gets blocked, but the time taken is about 5-6 seconds approximately for this operation.

If I move this code into a background thread, the UI remains responsive but the time taken almost doubles to 10-11 seconds. There is nothing different which I am doing, but is there any specific reason why this takes more time.

As of now not able to put any code. I tried increasing the thread priority too. It did not help.

Thanks

DeveloperGuo
  • 636
  • 5
  • 15
Sandepku
  • 861
  • 14
  • 31
  • Is the COM object instantiated in the UI thread then used in the background thread? – DeveloperGuo Mar 18 '14 at 04:45
  • Does the background thread have the same threading model as the COM object (usually STA)? It should execute faster if using the same model. If your background thread is a threadpool thread then it uses MTA. – groverboy Mar 18 '14 at 05:18
  • @DeveloperGuo Yes you are right, I am following the same approach. – Sandepku Mar 18 '14 at 06:03
  • @groverboy The background thread is a threadpool thread infact ! – Sandepku Mar 18 '14 at 06:04
  • Try instantiating the COM object in background thread. – DeveloperGuo Mar 18 '14 at 06:25
  • How do you interop with COM, wrappers/tlbimp or dynamic? – Boris B. Mar 18 '14 at 06:27
  • @BorisB. it is with wrapper infact. – Sandepku Mar 18 '14 at 06:34
  • @DeveloperGuo Tried this approach, I have an activeX control too which refuses to instantiate until, its a STA thread. So I am doing the same on UI thread. I can segregate activex and COM but its takes some time infact. – Sandepku Mar 18 '14 at 06:36
  • What I have done in the past working with STA Threads is construct and execute functions on the COM object using TPL Extensions StaTaskScheduler so that everything is executed on the same STA thread: http://blogs.msdn.com/b/pfxteam/archive/2010/04/07/9990421.aspx . – DeveloperGuo Mar 18 '14 at 06:41
  • @DeveloperGuo I can try this out, will keep you posted on this, but as of now, going with UI thread approach – Sandepku Mar 18 '14 at 09:44
  • @Sandepku, try `ThreadWithAffinityContext` from [here](http://stackoverflow.com/a/21371891/1768303). Keep your COM STA objects affine to that thread and use `async/await` to access them. – noseratio Mar 18 '14 at 12:13
  • @Noseratio thanks , shall try the same – Sandepku Mar 18 '14 at 12:56

1 Answers1

0

You should probably profile this to see when the execution of that background thread actually starts, and what it's actual time-consumption is - start to finish. There're a number of pretty decent profilers that can do this for you. Remember, when you create a separate thread, that doesn't mean that it necessarily fires up right at that instant. And something might be interrupting it (such as something higher in priority). Plus, when you executed it on your UI thread, it had your UI thread's priority: what priority are you setting the background-thread to? As DeveloperGuo suggests - you should probably instantiate the COM object on that background thread: if that object doesn't have to hang around, then it is generally cleaner and more efficient to make that thread have full responsibility for the COM objects and other resources that it uses, and just provide a higher-level abstract API for the rest of your program-code to use. These are just generic suggestions - can't get more specific without seeing code.

JamesWHurst
  • 493
  • 8
  • 14