Labview Read INI File Slow

[yiweihua2002]

Dear ALL:

      I have a VI use OpenG Read INI Cluster subvi to read a complex cluster data structure called step config data,and when I Run this VI,It sometimes read INI File quickly,and sometimes read INI File very slowly.If I want to speed up the read INI File speed,I must quit labview and restart it,and when I quit labview it will reports error just look like Labview Error Message.JPG

[Wiebe@CARYA]

My guess is there is some VI in the Get Data VI.vi that uses references to
the cluster to get all controls in it. There is a bug in 80. and 8.2, that
makes this very slow (sometimes, and when it does, you must restart LabVIEw
to make it fast again).

A solution that has worked for me is to let the sub VI's that use references
to front panel object to run in the User Interface thread. So in the VI
properties, under Execution, select UI Thread instead of same as caller.

Although this might solve the problem it is not at all desireable to put sub
vi's in the UI thread! But it seems to be the only way for now.

Regards,

Wiebe.

[parthabe]

Normally. the OpenG VIs are not slower; so, you should report to them or look for the same problem in the LAVA forums.

[Wiebe@CARYA]

This particular function does not have a NI equivalent, so it's no matter of
being slower....

Regards,

Wiebe.

[Rodnebb]

I've got the same problem - it takes from 4 to 20 SECONDS to write and read 2 ini file clusters.

The first cluster I write have a few text strings, an error cluster and some numbers.

The second is an array of clusters (I loop through the array and writes each cluster separately.) containing some text and numbers, most of it contained in sub-clusters.

With 0 or 1 element in the array it takes around 4 secs to write and read this to ini file. With 20 in the cluster this takes 20 seconds (on a cFP-2120).

The openG functionality here is quite nice, but if I can't fix this time problem I'm afraid its quite useless!

[Wiebe@CARYA]

Open the VI with the referencing in it. Change it's VI Properties, in
Execution, so that it runs in the UI Thread. For now, that seems to be the
only solution. At least it worked for me.

Regards,

Wiebe.

[Rodnebb]

which vi? How do I recognize it?

[Rodnebb]

I've tried changing the top vi to UI Thread, but this doesn't seem to have any effect. All sub vi's seem to have a setting "same as caller" so changing the top vi should be enough. (?)

[Wiebe@CARYA]

Somewhere there is a VI (I assume, but it seems to me to be the easiest way)
that has a property of the cluster "Controls[]", that returns all the
controls inside the cluster. Then, this array is probably feeded into a for
loop. The VI where this is happening, should be set to run in the UI Thread.

Regards,

Wiebe.

[tst]

---

Wiebe@CARYA wrote:
Somewhere there is a VI (I assume, but it seems to me to be the easiest way)
that has a property of the cluster "Controls[]", that returns all the
controls inside the cluster.

---

No, the OpenG VIs accept clusters as variants and use the type descriptor to analyze the variants and it needs to do this recursively. I have seen them react slowly, but I didn't try analyzing the exact source, because debugging dynamically called reentrant VIs is not that fun. I assume it's probably the recursive nature of the algorithm.

In this case, I'm guessing it takes time because there is an array of clusters and the code for analyzing the cluster has to be called repeatedly for each element of the array.

One way of getting around this would be to put the entire array into a cluster, but you should note that this will mean that you won't have each element as a section as you have now. Instead, you will have a period delimeted string for the name.