From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Maps are too slow (?)

Solved!
Go to solution

Hi to all

I am probably missing something, but i can not find it...

 

Let's say we have a big project and we want to pass data arround (like a database).

So let's say we choose to use a map to store the data, and store the map in a LV2 style global, to be able to read the data in different parts of the project.

 

If i implement about 2000 reads, of a small map with 2000 items, it takes more than one sec, in my computer!!!

How can i pass the map data in my progect, effectively?

 

Of course, a wire is not an option. Note, that the readings will take place in many different vis, in many different locations.

(the data.vi is inside the for loop to simulate the many different readings)

 

Thanks

LabVIEW could be the future... But bad management is killing it (see subscription model). It is NOT RECOMMENDED for new users.
Download All
0 Kudos
Message 1 of 18
(3,581 Views)
Solution
Accepted by topic author pante

You are doing this completely wrong, pumping the entire map data in and out of the subVI with each operation. The map does not belong on the connector pane at all. Make the subVI a proper action engine with a few states: (init, put, read).

 

All that belongs into the connector pane is the mode, the map entry, and some status as needed.

Message 2 of 18
(3,571 Views)

Yes.... of course....

 

Many thanks....

LabVIEW could be the future... But bad management is killing it (see subscription model). It is NOT RECOMMENDED for new users.
0 Kudos
Message 3 of 18
(3,559 Views)

Here's a quick draft. Of course you probably want to include more states and more details.

 

altenbach_0-1592574582615.png

 

Message 4 of 18
(3,544 Views)

Thank you for the example. Very helpful. But one question I have to this. How do I get access to this Map in other Vis. Let's say the Main_MODCA is a vi used for initialising and reading data and another vi should be accessing to the map for adding or changing data. If I don't have the map on the connector pane, I don't get access to it, do I? How does this work? Thank You. Background Information: I have a very complex structure with recursive callls and OOP. (Hierachy CEF Framework) where I want to use that.

0 Kudos
Message 5 of 18
(2,613 Views)

You get access over the VI which is non-reentrant.

 

You use the same VI, you access the same map.

 

Simple.

0 Kudos
Message 6 of 18
(2,606 Views)

Hi.

You mustn't connect the entire map to the connector pane. You must connect only one element. You will use that for reading or writing.

That way the vi will be really fast. The entire map will exist only inside the vi.

LabVIEW could be the future... But bad management is killing it (see subscription model). It is NOT RECOMMENDED for new users.
Message 7 of 18
(2,596 Views)

Hi, 

thank you. Mainly I got it now. Setting, reading and Initialising works fine but I also need the map to get all the data out at places where I don't have all the keys. So I need to put the map on the connector pane to get it out. Then the put times rise about more than 200times with big data sets even 4000 times. How do you handle such a problem. Thanks in advance.

0 Kudos
Message 8 of 18
(2,529 Views)

Basically you have an AE (Action Engine), your VI with the internal shift register/feedback node. You can make that Action Engine as complex as it needs to be. As long as your AE only supports read, write and maybe clear, you are definitely just creating a glorified global variable. The trick is to define the operations your AE can perform in such a way that you don't have to pull out all of the data each time for a certain operation.

 

This could mean that you need to add extra "actions" and extra controls to your AE, then perform the necessary work inside the AE rather than pulling out all the data and doing the work on the calling diagram. If that proofs to complicated since it interacts to much with the rest of your diagram to be able to put it cleanly inside the AE, you have basically a design flaw in your program logic and need to rethink your approach of storing this data from the ground up.

Rolf Kalbermatter
My Blog
Message 9 of 18
(2,516 Views)

Just FYI, there's a caveat to using an AE like this to store data- it doesn't play nice with reentrant independent callers. You can't use this as-is to store two different sets of data. You could modify it with a key to look up a specific map though, and have this AE index a bunch of internal maps by key. A map of maps if you will 🙂

Message 10 of 18
(2,502 Views)