slow f labview 2011

[instrumento]

So, this is on the NI website:

  http://zone.ni.com/devzone/cda/tut/p/id/4998

And I quote:

Second, ActiveX variants can cause serious performance issues when used in ways that are otherwise acceptable LabVIEW style. Normally, displaying the first few cells of a large 2D LabVIEW array generates a negligible performance penalty, because the user interface thread only has to update a few controls with new values. But display of a few cells in a large array of ActiveX variants (such as a database query) can be very slow and sometimes causes LabVIEW to crash. We’re not entirely sure what causes the problem, but it seems to affect only visible controls and not those in a subVI. (Deleting an indicator reduced a 26,000-element database query from 240 seconds to 7.) Until NI addresses this, be careful with large arrays of ActiveX variants.

This is exactly the issue I'm facing.  We're manipulating a large array of ActiveX variants coming from a database query, which is now very slow in 2011 and sometimes causes it to crash.  I specially like that the final statement "Until NI addresses this ...."

[SteveChandler]

---

@instrumento wrote:

So, this is on the NI website:

  http://zone.ni.com/devzone/cda/tut/p/id/4998

And I quote:

   I specially like that the final statement "Until NI addresses this ...."

---

Glad you found the issue. It looks like you are out of luck for now. I am not too surprised that it has been isolated to ActiveX. I would have been surprised if it were LabVIEW itself causing the problems.

[Ray.R]

Thanks for sharing that info.  It may help others with similar issues.

Hopefully a solution will be available soon.

[SteveChandler]

---

@Ray.R wrote:

Thanks for sharing that info.  It may help others with similar issues.

Hopefully a solution will be available soon.

---

The article is years old though so don't hold your breath. This probably is something that is outside of NIs control since it is an ActiveX problem.

But why display an array of variants on the front panel? Variants should be hidden from the user entirely. I am not an expert in ActiveX but I bet what is happening is that LabVIEW has to wait for a blocking call to ActiveX.

[instrumento]

I only think this is a problems similar to that one from 6.1 times that may have re-surfaced, not yet sure it is the right thing.

I'm not actively displaying the variant array, it just lives in some front panel that I never open.

Also, I do think this is a LabVIEW problem and not ActiveX.  On my example code, after getting the double array of OLE Variants, I can close all the VIs that use ActiveX and LabVIEW still gags working on it, so it may be an interaction with the ActiveX OCX and Labview 2011, but 2010 has no problem with it.

[SteveChandler]

Hmm. Good points. Hopefully someone at NI who is an expert in these things will weigh in. Lava has some very helpful and knowledgable people. You might want to post something there with a link to this thread.

[instrumento]

Found a workaround! It not only simplifies the code, but may also help NI figure out what is wrong.

I'm going to fully test it in LV2011/LV2010 and I'll post it back here later today.

And then I'm taking tomorrow off to take my mind off LabVIEW for the long (USA) Labor Day weekend 🙂

[instrumento]

The example code I posted a few posts back includes a VI named data-loader.vi where I loop over a double array of OLE variants that came from an ActiveX/ADO/ODBC call.  As we know the structure of the data in the cluster, in the inner loop we have a case structure where we do a variant to data of the appropriate data type, then format to string, if needed, for e.g. double values, and/or select empty strings if the conversion failed, which it will in case of null variants.  We then stuff that string in the text.text property of the control.

That code runs fine (fast enough) in LV7.1, LV2010, both 32 bits, not so fine (slow or crashes) under LV2011 64 bits.

I decided to try adding a double for loop over the variants and do a variant to STRING type data, and when that worked I now only have to feed the strings to the old double loop without having to do a variant to the appropriate data type and/or test for conversion errors.  This works just as well and fast on LV2010 and LV2011, under 4 seconds (under 3 seconds after I optimized a couple  more things in that VI.)

Not sure where 2011 is spending all the time, but I suspect is handling the NULL variants. I'll let NI have fun with it, but it sounds like a bug of some sort.

I'll attach images of the old and new code below.  Spent the whole week tracking this down, installing and uninstalling stuff...

[instrumento]

Those images were inline in my browser 🙂  Do they have to be approved or did I do something wrong?  I'll attach them here, rather than inlining.

[SteveChandler]

Thanks for posting back the solution and happy Labor Day!