How to improve performance of background task in WPF?

Question

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??

Answer 1

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