VI with Several XControls on nested tabs takes minutes to load in LabVIEW 2013

[jarcTek]

Hello all,

I have a VI in LabVIEW 8.2 that includes more than 400 Xcontrols in nested tabs, which opens in seconds (very fast). The code was upgraded to LabVIEW 2013 and now the VI takes minutes to open and in the meantime LabVIEW is unusable with the CPU at 100%.

I am wondering if anybody has experienced this behavior with Xcontrols.

Thanks.

[0utlaw]

Make sure you've mass compiled the project (and the Xcontrols) in 2013 - the most likely culprit here is VIs saved in older environments that need to be recompiled when launched in 2013.

If you haven't already, be sure to back up the project before moving the entire thing to 2013.

Regards,

[jarcTek]

Hi Tom,

Thanks for the answer. I had compiled the code before, but I did a mass compile just now and it did not help. It takes about 6 minutes to open the VI and finish drawing all the Xcontrols.

Do you see any other thing that may be causing this behavior?

[0utlaw]

Looking at the code (or a subset of it) would be helpful, but I'm very surprised that a mass compile of 400+ xcontrols (and the associated, presumably very large, project) took less than the time between my post and your new one (heh), how are these included in the project?  If you open up the facade of one of these XControls(or any other component, really) does it list the source version as 2013 in the VI Properties?

Also- to confirm, you see this when the VI is being opened from disk, correct?  Not when you run the VI.  Do you see a loading/compile window when opening the project and/or the top-level VI?

Regards,

[PJM_JKI]

Please note that I am working with jarcTek on this project where we inherite that UI with so many XControls instances.

It is not like there are a lot of different XControls (there are a total of about 10 different type of XControls), but there are a lot of instances of these XControls (several 100) in 3 levels of nested tabs.

Yes, we both had the time to re-recompile the source code between the two posts that jarcTek made. The various XControls are stored in 4 different llbs. Most of the XControls that have a lot of instances are actually pretty simple (very little code there). Finally, yes the VI property  (or the XControl library property general settings) indicate that the code is in LabVIEW 2013 [see image below]. 

You are correct, the delay occurs after the VI is loaded from disk. The loading time is fine (we see the loading progress/dialog since there are a few 100s vis to load with that main UI), but after that everything hangs for several minutes (cpu peg at 100%). We run the Desktop execution toolkit, and we can see a lot of XControl events (1000s) that are fired during this time.

FYI: Unloading (closing) the VI is also very slow.

To put this in perspective, In LabVIEW 8.2 the same code is ready to run immediately after the UI opens.

Thanks

PJM

[0utlaw]

Hello jarcTek/PJM_JKI,

That is curious, and I'm not sure what else you'd want to look for.  I did find a mention of an XControl performance decrease in this Known issues list:

LabVIEW 8.5.x Known Issues by Date

http://www.ni.com/white-paper/8145/en

Refer to # 68064 / 4DOC349I

It doesn't look like there is a workaround or bugfix listed in more recent release notes, so I'd recommend getting in touch with NI support directly if you need to troubleshoot this.  One thing that may be worth testing is seeing if the performance decrease is seen when migrating the original source to 8.5.1- if nothing else this would verify whether or not the issue listed there is actually the problem.

Regards,

[jarcTek]

From NI's answer to our support request:

"When you create a  XControl and you use it in an application you have to keep in mind that the loading time is 1 second for each XControl. Basically, each XControl is redrawing for the first load. This issue is known for our R&D Department since LabVIEW 8.5, they are still working on this and I can’t tell you when they are going to fix it."

[garrettmarsh]

I've seen similar behavior with XControls in 2013. They were created in 2011 originially, then ported to 2013, and things were fine for a few weeks. Then out of the blue I started to observe the same sorts of slow downs. Force recomplie and mass compile made no difference. After quite a bit of troubleshooting, I found that strangely, saving a copy of the .xctl library (File>Save As) would fix the problem. Doesn't matter where you save the copy. You can even delete it when finished. Something about that process causes the Xcontrol to 'reset' internally.

The problem still appears from time to time, usually after a heavy round of edits to the XControl Facades, and each time I fix it by Saving A Copy of each xctl library. Pretty annoying, but at least the code functions well now. 

[PJM_JKI]

Garrett

Thanks for the tip. At that point we pretty much removed 90+% of all the xcontrols so this is no longer an issue.This was quite time consuming and I would have loved to know about this "save a copy" trick a few months ago. In any case, this is good to know for the future.

Thanks

[Lee2845]

Just an update on this.......

I had a similar problem with a VI that used xcontrols (approx 200 nested within each other). In 8.6 it took approximately 2s to load, but when I converted up to 2014 about 30s (re-compilation, saving etc made no difference).

I fixed this by changing all of the (required) xcontrol 'Init.vi' VIs to execute in the 'Standard' thread rather than the 'User Interface' thread.

Now back to 8.6 load time!