Data Pre-Allocation With Conditional Data-Type

[tsa256]

Hello everyone,

I have a quick question. I have recently begun learning the advanced LabVIEW memory management techniques and have been wondering if it is possible to allocate a large quantity of memory outside and before the main loop then convert that pre-allocated data into a specific data type depending of a condition.

For example lets say I allocate 100 Megabytes of "Data Type A" before the main loop execution begins. Then within the loop there is a condition that determines what the program will do. Lets denote these states (conditions)  X , Y and Z. In State X the program does not want "Data Type A" for processing but requires "Data Type B". Is there a way to convert the preallocated data from "Data Type A" to "Data Type B" so that LabVIEW does not have to reallocate more Data? A similar problem occurs in State Y where the state is asking for "Data Type C". I think you get it. Finally, in state Z the state requires an input of "Data Type Z"

What I'm trying to accomplish is preallocated data but depending on different conditions change the data type for the preallocated data to facilitate different calculations. How can I accomplish this? I was breifly told to use a variant data type but I am inexperiance with that function and am unaware of the speed effects, memory effects, and other aspects of implementation.

Any help would be greatly appreciated.

[Drew_T]

Taylor,

Are you familiar with the Conversion Palette: http://zone.ni.com/reference/en-XX/help/371361G-01/glang/conversion_functions/

These VIs will convert data to specific formats.

Something that may in fact be more useful for you, is the Type Cast function: http://zone.ni.com/reference/en-XX/help/371361G-01/glang/type_cast/

This VI will convert formats by flattening then unflattening the data into the format specified.  

Finally, you can use this function with a Variant data type: http://zone.ni.com/reference/en-XX/help/371361G-01/glang/variant_to_data/

Please let me know if you have anymore questions!

[nathand]

What are you trying to gain here?  It doesn't make sense to try to outsmart the LabVIEW compiler on memory management, because LabVIEW is free to move, reuse, and allocate memory however it sees fit.  Also, allocating memory is a fast operation; copying data into that memory is slow, but you can't avoid it even with preallocated memory.

[tsa256]

I'm attempting to gain more control of LabVIEW memory usage. I've looked into all of the options listed above and for the most part understand how they could work. I just can't seem to have success implementing it into LabVIEW when the memory required in the loops is different. For example I preallocate 16 megabytes and one loop needs to do operations on two 8 megabyte datatypes while the other loops does operations on 16 megabytes of a different datatype. I understand how to convert but how would I split data up to do different calculations on each.

Thanks you

[nathand]

Can you share any code that demonstrates what you're trying to do?  Why is this a concern for you?  One of the advantages to LabVIEW is that you don't have to worry about memory management, but the trade-off is that you have limited control over it.  You cannot force LabVIEW to use a particular block of memory for a particular purpose; the best you can do is make as many operations as possible "in-place."  There's no direct equivalent of malloc() to allocate a generic block of memory that can be used for any type of data; whenever you convert data from one form to another there is the possibility that LabVIEW will move it to a new location.  Also, as I mentioned before, allocating space in memory is computationally cheap (and with virtual memory in modern operating systems, it's almost unlimited unless you're getting into massive data sets).  Copying data is the slow part, thus the reason for making operations in-place.  If you have a bunch of data somewhere and insist on copying it into your pre-allocated array, that will quite likely be slower than doing the operations on the data in the original location.