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

[Intaris]

As JArcTek says, there is a known bug (I don't have a reference number) which states that each XControl takes around a second to initialise, irrespective of the code state of the actual work being done.

The problem is known and I'm assuming NI is working on fixing it.  Several 100 XControls (irrespective whether it's 500x the same XControl or 500x different XControls) will each take approx. 1 second to initialise, hence the several minutes delay.

[Lee2845]

Thanks for the reply, but the change I detailed in my previous post does seem to fix it without any detrimental effects (as far as I can tell).

In 8.6 the 'initialise' part of the xcontrol is set to run in the 'User Interface' thread but the xcontrols update quickly when loaded. In 2014 (and I think at least 2012 & 2013) the same execution thread causes a long delay as each xcontrol appears to run the initialise consecutively - similarly to updating normal controls without deferring front panel updates.

Changing the execution to the standard thread appears to allow the initialise to occur in a similar fashion to deferring updates (they appear to update their facades quickly and at the same time)

If anyone is having this problem I suggest just creating a lot of xcontrols in a VI and trying it - the effect is obvious.

[Intaris]

Really? that sounds like a really cool tip, make sure you pass that on to NI.

I wonder if there's any reason why this shouldn't be done per default?

[Lee2845]

Intaris, thanks for the link to the response from NI, but the fact that they suggested that the 'bug' was introduced in LabVIEW 8.5 doesn't seem to tally with my experience of xcontrols in 8.6, and even if that was the case, that was about 7 years ago so I wouldn't hold my breath for a fix from R&D!

It would be nice if someone could independently verify that changing the execution has an effect on the loading of xcontrols in a VI - would you like to volunteer?!

Just putting maybe 40 instances of the thermometer xcontrol example in a VI, saving then re-opening should be good enough to confirm that this works (or at least helps!)

This is (was?) a big deal for me as it would have required at least a month to re-implement and test a 'normal control' alternative, so would be nice to have more confidence that it might be a reasonable fix! 

Thanks,

Lee

[Intaris]

I did a test with 64 copies of my own XControl which in itself consists of 4 Xcontrols each, that's a grand total of 380 XControls.

With UserInterface setting, it took about 15 seconds to load the FP, with Standard setting it took approximately 4 seconds.  I thought maybe the Standard setting was simply sharing the work among many cores (I have a quad core CPU with Hyperthreading - 8 cores total) but in both cases the CPU load for LabVIEW when opening the VI was 13%, 1 core.

I'll certainly be leaving all of my XControls set to standard until someone can tell me why I shouldn't.

My tests were performed in LV 2012 SP1 (32-bit) on Win 7 64-bit with 8GB RAM.

[Lee2845]

That sounds about the same as I'm getting with 2014.

The tests I originally did were with the xcontrols in a plugin - so the 4s were probably masked a bit by the rest of the VIs being loaded. The load of the VI on its own is still slower than the equivalent in 8.6 but at least it's useable!]

I also wondered if the improvement was due to my quad core, so glad to see it isn't!

I haven't built this into an exe yet but will be doing so this afternoon so hopefully it will still work without any issues.