FGV with variants

[SeSandoval]

Hi, my name's Miguel, and i would like to get some feedback about this FGV. 
For my main application i'm using the QMH Architecture (with only 2 loops), the message handler loops needs to pass data between one state to another, but i dont want to use shift registers because of performance. Is this the best way to pass data between loops or should i create another two loops (one for handling the database logging and the other one for acquiring the data)?

This is my first post, so please tell if did something wrong.

I will give kudos to all the good answers and opinions.

[altenbach]

(Posting by phone, cannot look at your code)

Shift registers are one of the most efficient ways to carry data between iterations, so I don't understand you performance concerns.

[SeSandoval]

Because i'm already using shift registers for other things, and i'll be having a great amount of data, and i don't think that using arrays to store data will be the answer.
That's why i though about using a Look up table.

That doesn't matter?.

By the way, thanks for your reply. I really appreciate it. 

[altenbach]

I am not quite sure how your attached FGV fits in the rest of the code. Why are the attributes variants? Do they have attributes themselves? How are you actually using all this?

In terms of performance, you should place all connected terminals on the main toplevel of the VI, not inside structures. (details). I would also eliminate the while loop and replace the shift register with a feedback node. Now you can globally initialize it with an empty variant.

How much is "a great amount of data"? What are the datatypes?

[drjdpowell]

Because i'm already using shift registers for other things, and i'll be having a great amount of data 

---

Use a cluster of data in a single shift register.   Especially for a large amount of data, as a shift register generally involves no copying of data and has zero performance cost, while other methods like your FGV do involve copies.

I suggest you experiment with different methods, using some very large strings to measure performance.

[wiebe@CARYA · Accepted solution]

Using a FGV like you made will not be optimal for performance. The variant conversions will slow down things, and there will be copies of the data from \to the buffer. The variant lookup uses a tree search, so it's pretty efficient. But an enum that is an index in an array will still be more efficient. So if you can replace the strings with an enum, and store the data in an array of variants, it will probably be faster.

Shift registers (several SR's or a cluster with one) can avoid copies of data, and have no conversion.

SR are the most efficient, but won't communicate data between loops. So if you want to distribute the data throughout the application, a FGV is a solution.

Communication between loops can also be done with e.g. queues and user events. Both will be efficient, but the module is different. There won't be a centralized generally accessible data buffer, but localized data. For me, the localized data is preferred for several reasons that are OT.

The risk with FGV (and any kind of global) is that your code gets unnecessarily coupled. Also, it can be hard to trace back where you read\write the individual variables. But that's another topic...

Do you have reasons to be worried about performance? As long as you work modular, you should always be able to switch implementation when needed... Don't optimize until needed.

[SeSandoval]

Thanks to everyone for your support. I really appreciate it.

I think i'm going to use another 2 loops (one for Acquisition and the other for logging). 

I wasn't thinking in data buffer (my mistake), and i'm going to need to pass data between loops, so i'll use queues and a string-based messages.