Constructing a WPF window from an express VI is slow

[astibich]

We are trying to popup a WPF window from an express VI, but the window construction time is an order of magnitude longer when it is created within the LabVIEW process. To reproduce this problem, perform the following steps:

1. Unzip the attached LVTest.zip file

2. Install the express VI under LVTest\ExpressVI

3. Open LVTest.sln in Visual Studio 2010 and build

4. Run '.\LVTest\bin\ConsoleApp.exe' OUTSIDE VISUAL STUDIO. You should see a blank WPF window popup.

5. Close the window. The console app should shutdown.

6. Find the 'Timing.txt' file (on Windows 7, it should be at 'C:\Users\Public\Documents\Timing.txt') and open it. Take note of the WPF window construction time. On my laptop, it's about 120 ms.

7. Run LabVIEW and start a blank VI. You should see the installed express vi from step 2.

8. Create the lvtest Source.vi. This should result in the same WPF popup window.

9. Close the popup window and close LabVIEW without saving.

10. Open timing.txt again and take note of the WPF window construction time. On my laptop, it's about 1500 ms.

The timing data is JUST the time needed to construct the WPF window.

                       Stopwatch sw = new Stopwatch();

                        sw.Start();

                        MainWindow w = new MainWindow();

                        sw.Stop();

                        writer.WriteLine("Constructor: {0} ms", sw.ElapsedMilliseconds);

As you can see, LabVIEW is taking 10x the time to construct an empty WPF window. Any idea why?

Thanks,

Aaron

PS. Building LVTest.sln installs MyWPF into the GAC (that's how the express VI finds it). If you like a tidy GAC, uninstall it when you're done with this issue.

[Che_T.]

<edit>

[Che_T.]

Hi astibich,

I opened up the file 'ExpressVI\Test\_lvtestConfig.llb' and examined it.  I was able to replicate the issue that you're seeing, where it takes 1500ms to open up a blank WPF window.  To test whether or not the 'Invoke Node' function was faulty, I changed the method to 'GetHashCode()' and 'GetType()'.  Those methods executed fine.  This leads me to believe that something is faulty in the ShowWindow() function.  Because you're using threads, it does add a level of complexity compared to a sequential program, so it is a little harder to troubleshoot

At this point, we know that the slowdown is occurring at a level lower than the Express VI. I'll see if other people have had this issue.  In the meantime, I'd suggest looking through your code, and if possible. remove the threads to see if performance is different.

[astibich]

The console application uses EXACTLY the same code path (including generating an STA thread) and doesn't suffer a slow down.

[Che_T.]

I do agree that it doesn't perform as expected.  They're both calling the same codebase.  It's hard to determine what's causing the slowdown.  At this point, it occurs at a level lower than Express VI, and other .NET functions ran quickly with the Invoke Node.  It is definitely an interesting issue.  Were you able to diagnose it any further? 

[astibich]

Can you give me any details about how how LabVIEW makes the call to the express VI? Does it create an application domain? If yes, how is it constructed? With any luck, we can reproduce this problem outside LabVIEW.

[Che_T.]

Hi astibich.  I don't think that it is an Express VI issue.  Whenever I did my experiment, I ran that VI as a normal VI instead of as an Express VI.  It still is odd that it takes so long to create the WPF window.  I'll get some more details for you.