Labview Read INI File Slow on cFP

[Rodnebb]

I 've thought about putting the arrays into a cluster, but this isn't going to be neat, and anyway by now I can just as well write some code for creating a ini file instead, it's not going to be more work.

Any better workarounds? Actually, what I'm currently writing is just clusters in clusters - it strikes me as odd that the openG guys think such slow perfomance is ok. I consequently can't free myself of the idea that it should be possible to do this much faster.

[TCPlomp]

---

@Rodnebb wrote:

Any better workarounds? Actually, what I'm currently writing is just clusters in clusters - it strikes me as odd that the openG guys think such slow perfomance is ok. I consequently can't free myself of the idea that it should be possible to do this much faster.

---

Hi Rodnebb,

why don't you join us? If you have some nice VIs developed or time on your hands you are more than welcome!
Just drop a post in this forum and you will be contacted.

Ton

[tst]

---

Rodnebb wrote:

I 've thought about putting the arrays into a cluster, but this isn't going to be neat, and anyway by now I can just as well write some code for creating a ini file instead, it's not going to be more work.

---

How not? This workaround simply requires that you get rid of the for loop, wire the array of clusters into a bundle node and wire the resulting cluster into the Write INI Cluster VI. I doubt you can get anything which will require less work.

---

it strikes me as odd that the openG guys think such slow perfomance is ok. I consequently can't free myself of the idea that it should be possible to do this much faster.

---

Apparently, the MGI VIs do it faster, but they use tools released only with LV 8.0, and the OpenG VIs were around long before that. The slow performance comes from the recursive parsing of the variant. I think that the OpenG people (specifically, Jean-Pierre Drolet) did a superb job with this code and I don't think that performance issues in corner cases should have been a major concern.

You should note that you are not just writing clusters in clusters, but that you are doing this in a loop - the code has to parse the clusters for each element in your array for no good reason. If you called the write VI once I'm sure it would take significantly less time.

[Rodnebb]

TonP: I've already joined the forum - waiting for a reply 🙂

tst: Getting rid of the array shouldn't save me much time (not enough), as I'm already only running the for loop a handful of times - and if I run it once it takes me 4 secs - which is way too much any way you see it. Rewriting to get rid of the for loop can be considered when I have gotten the read/write section cluster down to the ms range. I can also reduce the amount of data written to file, but I'm not writing orders of magnitude more data than I need, so this still won't make me arrive.

I'm wondering if the recursive nature of my clusters (cluster in cluster) can be to blame, I'll try timing writing a cluster with only one level in it later. But I was guessing that there's something in the way I use the opengG vi's that caused a bug to appear. (or that these vi's are simply not intended for embedded apps????)

[tst]

I missed the fact that you are doing this on a cFP. File I/O and dynamic memory allocations are killers in RT targets and this is definitely both (converting to variants and loading dynamic VIs are both quite demanding in terms of memory). The OpenG VIs were not designed to be fast, especially not in RT targets. In fact, even the NI VIs they use are old and rather inefficient and I would avoid using them in an RT target.

Options:

1. Move this to a lower priority thread (parallel subVI) so that you don't care how long it takes. You should do this anyway, because file I/O should not interfere with your time critical code even if it is fast.
2. If you still want to do this in the same loop, move to binary files. You can easily flatten your cluster to a string and read it back, but the disadvantages are that the file won't be readable and that it will not be compatible with future versions of the cluster.
3. Another option is to send it to be done on a PC, but I don't think you will gain anything from that.

[Wiebe@CARYA]

You could also flatten the cluster to XML, and read it back again. It's not
ideal, especially if the cluster is still changing, but it will probably be
a lot faster then variants.

Regards,

Wiebe.

[yiweihua2002]

If I Use write to binary File instead of Write INI Cluster,It Will faster?

[Sherman]

Yes, it will be faster

[Rodnebb]

But the point here is the ability to just write the clusters you anyway use directly down to an ini file, and then pick them right up again next time. This is only achievable by the OpenG vi's, or?

[tst]

---

Rodnebb wrote:

But the point here is the ability to just write the clusters you anyway use directly down to an ini file, and then pick them right up again next time. This is only achievable by the OpenG vi's, or?

---

Writing to a binary file will do that as well, since the file primitives can accept and return any data type and you can also flatten the data to a string. There should be some examples in the example finder (Help>>Find Examples)

The OpenG VIs give you two advantages -

1. They produce a human-readable file (that can also be considered a disadvantage).
2. If you change the format of your cluster (add or remove elements), you will still be able to use files saved using older versions of the cluster, whereas the binary read will throw an error because it can't convert the old version to the new version automatically.

The price you pay for these advantages is speed and memory - it takes time and data copies to generate the INI format data.