LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how to deallocate memory without reinitializing shift register

I've read a couple posts about similar issues, but I did not see any thread directly addressing what I have in mind. I'm taking a large data set and performing some statistical calculations on it. Also, there are some uninitialized shift registers that I am using to process the data. After finishing my calculations the program waits for the user to decide to do some other function in the program. I'm curious about why exactly it behaves the way it does (and what I could do to improve it): THe first time I open and then run my vi it runs well, but if I perform the calculation another time without closing out of labview it takes at least twice as long. My guess is that the data is remaining in the shift registers and building up. I'm not sure what I could do about it though. The only ways I could see of doing this is reinitializing the shift registers or maybe making the calculation a subvi and using the "request deallocation" function.
0 Kudos
Message 1 of 7
(4,790 Views)
Why don'y you use initialized shift registers then??? You can also clear an shift register containing an array by conditionally feeding an empty array to the right terminal while the loop is running.  
 
Are you building arrays in shift registers? It is always more efficinet to allocate the shift register as a fixed size array, then use replace array subset to feed it your new data. This avoids constant memory allocations. If you want, attach your code and we have a look at it.
Message 2 of 7
(4,775 Views)
Thanks for your reply altenbach!
feeding an empty array to the right terminal seems pretty clever to me. I used your suggestion to use replace array subset and it works well. Thank you.

In a similar vein, my program takes the longest amount of time on the ending of a for loop. I believe the friction occurs at an auto-indexing output. After reading data from a file, data is broken into 1d arrays which are indexed first into a 2d array. Then, (where it seems to creep), these are indexed into a 3d array. There is nothing else going on really, the whole reason for going through the process of unbundling the data and then rebuilding it into arrays is to seperate the X and Y data streams which are originally bundled in the data. The 3d array has about 16000 elements to put together during the final indexing.

So, my question is whether the auto-indexing is equivalent to using build array functions or replace array functions or is it done in some other way. And are "build array" and "insert array" functionally equivalent if you continue to iterate to the last element/row? Also, I read someone say that multiplying an array of float values to turn them into integers could ease data manipulations. Is this true?

I would like to post my code, but unfortunately the computer with labview and the computer with internet are not the same. I can't imagine that my explanation of the code is perfectly clear, so if you want me to clarify or expound please ask me to.
0 Kudos
Message 3 of 7
(4,756 Views)
edit: the 3d array has about 62 million elements to index once the outer loop finishes; there are 16000 2d arrays

Message Edited by kaufman on 06-27-2006 12:36 PM

0 Kudos
Message 4 of 7
(4,726 Views)
Kaufman,
You've asked a great question "is  the auto-indexing is equivalent to using build array functions or replace array functions". The answer is no. The build array function and insert into array function constantly have to reallocate memory because LabVIEW has no idea how big an array is going to be. Resizing takes time and memory. By contrast, with for loop auto indexing, LabVIEW knows based on the number of iterations how large an array will wind up being and therefore memory can be allocated only once. The number of iterations is known before the loop begins. Using the buld array function in a looping structure can be very dangerous because it can grow with out bounds and consume your computer's resources.
 
As a side note, you can actually see where LabVIEW is allocating data by using the Tools>>Profile>>Show Buffer Allocations. You can find help for this tool here.
 
Also, in terms of memory usage, there is no difference between build array and insert array. Both involve array resizing. Again, doing this in a looping structure will eat up your computer's resources.
 
I'm not quite sure I understand your second question about multiply floats to get integers.
 
Post to let us know if you have other questions!
 
Chris C
Message 5 of 7
(4,703 Views)
Thanks Chris, that helped me figure out how to optomize my code. And the "show buffer allocations" tool is pretty neat. After all this time, I missed that somehow.

My question about multiplying floats was kindof a side curiosity. At some point I read or heard someone say that instead of performing mathematical operations or labVIEW functions on floating datatypes, one could change them to integers to improve efficiency or speed. You could multiply the decimal values by some constant and change them to integers, do the operations, and then change them back to float and divide by the same constant. The theoretical hypothesis was that the operations would run faster or more efficiently on integers than floats and the multiplication/division would give you back the same value you started with. Is there any plausability in this?

edit: this is assuming you have a lot of operations, enough to justify the datatype switching

Message Edited by kaufman on 06-28-2006 10:01 AM

Message 6 of 7
(4,687 Views)
Hey kaufman,
Glad to hear that some of my suggestions helped out! And you're right, that "show buffer allocations" tool is pretty neat.
 
I can't think of a good reason why it would be more efficient to preform operations with a float instead of an integer and I haven't read anything to that effect. I think you're pretty safe not doing the conversion. Although you could test it and do a benchmarking study... if you do, post to let us know what you find.
 
 
Chris C
0 Kudos
Message 7 of 7
(4,669 Views)