I'm building a WPF app which will do some heavy work in the background. The issue is that when I run the task in the unit tests, it usually takes about 6~7s to run. But when I run it using TPL in WPF app, it takes somewhere between 12s~30s to run. Is there a way to speed up this thing. I'm calling COM api of LogParser to do the real work.
Update:
My code for calling Log Parser API looks like below
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();
The thing now is with this change, I can see about 3 - 4s improvement in debugging mode, but not when I hit Ctrl + F5 to run it which is quite beyond me. How come??
The problem here is that the COM object you're using will only run on an STA thread. Several people already suggested this, but I decided to check, just to be sure. I installed the LogParser SDK, and here's what it puts in the registry for the CLSID associated with the MSUtil.LogQuery ProgID:
[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"
It's that "ThreadingModel"="Apartment" that's the clincher. This COM class is declaring that it can only run on an STA thread.
Both the TPL and the BackgroundWorker use MTA threads. The consequence of this is that when you use the LogParser from either a TPL task or a BackgroundWorker the COM runtime detects that you're on the wrong kind of thread, and will either find or create an STA to host the object. (In this particular case it'll use what's called the 'host STA', a thread that COM creates specially for this purpose. There are some scenarios in which it'll use your main UI thread instead, but that's not the case here.)
COM then automatically marshals any calls from your worker thread over to that STA thread. It does this via a Windows message queue, so for each method you execute (and remember, property accessors are just methods in disguise, so this applies to property use too), your worker thread will send a message to that STA thread, that STA thread's message pump then has to pick that message up and dispatch it, at which point the COM runtime will call the method on the LogParser for you.
This is slow if you've got an API that involves a high volume of calls.
This is neither a WPF nor a Windows Forms issue by the way. It is entirely to do with using an STA-based COM object from a non-STA thread. You could reproduce exactly the same problem with a console app too, if you were using a non-STA thread in that. And the problem isn't specific to either the TPL or the BackgroundWorker - it will afflict anything that uses the thread pool, because thread pool threads all use MTA, not STA.
The solution is to use an STA thread. And the best way to do that is create a dedicated thread. Use the Thread class in the System.Threading namespace to launch your own thread. Call its SetApartmentState method before starting it. Make sure that the code that creates instances of objects from the LogParser API is running on that thread, and also make sure that you only ever use those objects from that thread. This should fix your performance issues.
Edited 21st Feb 2013 to clarify:
Note that it's not simply enough to ensure that you are using the COM object from an STA thread. You must use if from the same STA thread on which you created it. Basically, the whole reason for having the STA model is to enable COM components to use a single-threaded model. It enables them to assume that everything that happens to them happens on one thread. If you write multi-threaded .NET code that uses an STA thread from multiple threads, it will, under the covers, ensure that the COM object gets what it wants, meaning that all access will go through the thread it belongs to.
This means that if you call it from some other thread than its home STA thread, then even if that other thread also happens to be an STA thread, you'll still be paying the cross-thread price.
Edited 25th Feb 2013 to add:
(Not sure if this is relevant to this particular question, but could well be of interest to other people landing on this question through a search.) A downside of moving work onto a separate worker thread is that if you want to update the UI in any way as a result of processing these records, you're now on the wrong thread. If you're using databinding an INotifyPropertyChanged, WPF will automatically handle the cross-thread change notification for you, but this can have significant performance implications. If you need to do a lot of work on a background thread, but that work needs to end up updating the UI, you may need to take steps to batch those updates. It's not completely trivial - see the series of blog entries starting here: http://www.interact-sw.co.uk/iangblog/2013/02/14/wpf-async-too-fast
COM uses message queues for IPC. I'm unclear what determines which message queue, but I suspect it's the shell message queue because the Delphi debugger and Outlook used to play merry hell with each other. My unproven hypothesis is that an out of process COM server can be stalled by something else stallings the shell message queue. Windows has timeouts to prevent this sort of thing from totally locking up the system but it can cause massive slowdown in affected processes. My solution would be to avoid COM. You could check this by commenting out the parts that actually use COM and timing the process.
Related
I have a CAD plugin application. In my CAD application program, CAD may have restrictions about which thread can be used to modify the CAD body.
Here is my requirements:
Since COM call are received on different threads, then the plug-in must ensure that all construction calls are made in the right thread (the main one).
Also, since the kernel can call the plug-in while the CAD is busy, the plug-in must ensure that it can safely call the constuction thread without creating a deadlock.
A valid solution could be to check if the Main (construction) thread is busy before trying to use it.
So my question is: How to check If main thread is busy or not?
I had a similar issue and solved it in the following way:
ManualResetEvent waiter = new ManualResetEvent(false);
control.BeginInvoke((Action)(() => waiter.Set()));
bool threadIdle = waiter.WaitOne(timeout);
Set timeout to what ever wait-time you want (500ms for instance)
I have a C# Winforms application that talks to a USB device through a vendor library. I run this interface with a background thread. During the vendor constructor, the entire Winforms application GUI is frozen. One core of the CPU is at 100%, but the other cores are idle. How do I determine what calls the vendor is making to block the GUI?
I run the background thread like this -
public HardwareInterfaceClass() {
var hardwareThread = new Thread(HardwareInterfaceThread);
hardwareThread.IsBackground = true;
hardwareThread.Name = "USB Interface Communication";
hardwareThread.Start();
return
}
private void HardwareInterfaceThread() {
var usbInterface = new USBInterfaceHardware(0); // Takes 5 seconds and blocks GUI
...
}
There is nothing at all in the code you posted that would block the UI thread. So there are two possibilities:
There is something in the library code you are calling that is blocking the UI thread.
The UI thread is not really blocked.
It's impossible to know for sure which is correct, though the first option would be very unusual, especially if you hadn't actually passed anything to the library code that would even tell it where your UI thread is (but not impossible…it could have logic internally that seeks out your UI thread and somehow messes with it).
If the second option is correct, then the UI could seem to be blocked, but simply not getting enough CPU. The fact that your other CPU cores are idle suggests this isn't the problem, but given how remote the first possibility is, it's worth at least considering.
If your background thread is taking CPU time away from the UI thread, then you can fix that by setting hardwareThread.Priority = ThreadPriority.BelowNormal;. Indeed, this is a good idea to do for any thread that spins consuming 100% of a core's CPU time.
There is, of course, a third possibility: in your own code, you have somehow caused the UI thread to be blocked while this background thread is working. But without a concise, complete code example it would be impossible to explain where that is. We can only look at the code you posted, and that code doesn't block the UI anywhere.
I'm building a VSTO add-in: I need to run a background thread, but this thread needs to access COM components (I've implemented IMessageFilter to make this messaging as safe as possible). All threads which access OLE or COM have to be STA I believe; thus, BackgroundWorker is off the table.
I am happy to use the normal thread and set the ApartmentState to STA, but I also need to know when this thread as finished so I can update some UI stuff. I do not want to Join() because it will lock the UI (which is the whole reason I'm using threads!).
Is the best practice to trigger some kind of event at the end of my threaded method, and have the event do the onfinished stuff I need?
OR
Is it better to poll
while(!_threadFinishedStarting)
{
Application.DoEvents();
Thread.Sleep(100);
}
As mentioned here: C#.net - How to alert program that the thread is finished (event driven)?
Thanks so much
You can call Thread.SetApartmentState() to select an STA before you start the thread. You must also pump a message loop, a requirement for STA threads. That tends to be difficult and is often skipped, you know you need one if your code deadlocks or your IMessageFilter complains.
Beware of the other requirement, an STA is only efficient when you also create the object you want to use on that same thread. That tends to be a problem in a VSTO add-in, you normally want to use an object provided by the Office object model. You don't get to choose where that object was created.
If that's accurate at all then you are not ahead with creating your own STA thread since the calls get marshaled anyway. In which case a BGW is just fine since you can't get ahead anyway, the call gets marshaled in both cases. There is no free lunch for thread-safety.
I have a slow method that I'd like to run in a separate thread.
This method uses a call on a COM object created in the main thread of the app.
Lets assume the code that is slow is this:
var bwImg = image.GetBitonalImage(); // <- slow image is a COM created in main thread
viewer.Document = bwImg; // <-- ATL control accepting the B/W COM image
If that matters, I am doing this in a WPF application and 'viewer' is in a WinFormsHost.
I assumed that doing this would make this asynchronous and not block the running of the application:
var t = new Thread((ThreadStart)(() =>
{
var bwImg = image.GetBitonalImage(); // <- this is in separate thread
Dispatcher.Invoke((Action)(() =>
{
viewer.Document = bwImg; // <- this again on the main
}));
}));
t.Start();
It is ok for me that the images gets shown at some later time, and I do not care how much later.
But it happens that the application is blocked in the same way.
I did profiling and indeed most time is spent in GetBitonalImage, and almost none in 'viewer.Document = bwImg'.
Removing the code altogether makes the app responsive, so it's not other code fault.
There is other code later after this that uses the same image COM object (not the B/W result but the original).
Is this the correct way to do this? Can the problem be because of the COM object method call?
Is your COM object threadsafe? If it's not, then it might be initialized in STA (single-threaded apartment) mode, which would use the STA thread to do its work. So even though you spun up a new thread, it would switch back to the STA thread, blocking your UI events. If you have control over the source for the COM library you could change those settings, as long as the code is actually threadsafe.
Edit: Found this link in the related posts section, it might be applicable to you. UI thread is blocking a background thread calling a COM object.
Correct in this situation has a lot of different meanings. :/
Can the problem be because of the COM object method call?
Well, if you remove that call and the application runs faster then I'd say: yes..
Is this the correct way to do this?
The best answer is is a question: does it work? If so, then you are probably on the right track.
It's hard to say for sure because I have no idea what the com object does. Is it designed for single threaded operation? How is it going to behave if multiple threads create instances? In other words, is the com object itself thread safe? I imagine you'll find out the answers to that soon enough.
Now to a broader question:
Is this the correct way to handle long running asynchronous processes?
Yes.
I have this simple code:
public void Run()
{
var invokerThread = new Thread(new ThreadStart(RunOnBackground));
invokerThread.Start();
}
private void RunOnBackground()
{
Trace.WriteLine("hi");
...
}
Unfortunately when running this code (from third party process) the thread doesn't really run.
Either in process explorer and in VS debugger I see that the thread is created and its state is "Running".
The main thread's apartment is STA and I've tried both STA and MTA on internal thread.
When I add to the Run() method at the end invokerThread.Join(); then the thread does run. But then again it doesn't really help.
What am I missing?
Edit: Here is some more information regarding the code hosting -
Run() method is called via COM interop from a process which is also managed executable assembly (the reason COM interop is used is because all other components in the system are native).
The method RunOnBackground() includes some more code after the tracing and generally its execution lasts between 10 - 20 seconds, including starting another process and waiting for its termination. Also I have some other areas in the code where I write some debug information to the Trace. While debugging the code, Run() runs as usual and after invokerThread.Start(); invokerThread's state is "Running" (though breakpoints inside the RunOnBackground() method don't stop).
When I add invokerThread.Join() at the end of the Run() method the debugger goes to RunOnBackground() after the Join().
There's some crucial information missing about what RunOnBackground() really does. This is otherwise a good match for what happens when you use apartment threaded COM objects on a worker thread. COM automatically marshals any method call on such an object from the worker thread to the STA thread on which it was created.
That can only work well when the STA thread observes STA threading requirements. It must pump a message loop and cannot block. Breaking those rules makes deadlock very likely, the worker thread call cannot complete until the STA thread dispatches the marshaled call. A sure sign that this is what is going on is seeing Thread.Join() solve the problem. It pumps a message loop internally in the CLR when it is called on an STA thread.
To diagnose this, you'll need Debug + Windows + Threads to see what that worker thread is blocking on. If my guess is right, it will be buried deep inside of the COM plumbing code, waiting for the marshaled call to complete. You can only see this by enabling unmanaged code debugging and setting up the Microsoft Symbol Server so you get debugging symbols for the plumbing code and get a reliable stack trace.
Fixing this is going to be difficult. You cannot magically flip a switch and make code run on a thread when it has explicitly stated that it doesn't support multi-threading. It is imperative that you create the instance of the COM object on the same thread that calls its methods. And that thread has to be an STA thread. Check this sample code for the approach. If you don't control the creation of the COM object then you're stuck.
I may say something stupid, but here is what I saw in MSDN Threads.
Look at the examples section at the end.
The output of the example is interesting, you can see there that the Thread created and started only starts executing when the main thread does a Sleep(0) or a Thread.Join().
It seems to be what exactly happens to you, doesn't it ?
Maybe try with a Sleep(0) on your main thread to really launch your working Thread.
Another workaround would be to use the BackGroundWorker.
As its name says it, it works on the Background and is really easy to use. It may be of much use to you.