LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Build Array and String Concat

Hi all,

 

I read a community nugget about string concat and build array in a loop, and it got me thinking.  I know about how using build array in a loop inappropritely could create memory problem due to the changes in memory size of the array for new elements.  I have read a few ways to solve this problem. 

 

The nugget that I read said something about using concat string, and how it could have the same issue.  From the nugget, I became aware of the problem, but I did not see ways to solve the problems. 

 

Let say that I am using concat string in a loop.  At every iteration, the loop will concat the string from the previous iteration with a new string and output the string to a indicator.  String from each iteration will continue to concat.  As you can see, the string is going to get longer and longer.  This is like a running log that show all the string from the past and also present. 

 

Would there be a memory problem?  If so, what are the many ways that I can resolve this problem?

 

Yik

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 1 of 6
(3,507 Views)

If you understand the memory issues with using Build Array in a loop and the ways to mitigate them (preallocation and replacement), then you have completed more than half of the battle.  Now when you recognize that using concatenate strings in a loop is a similar operation you can think about minimizing calls to the memory manager using the same techniques.  In C you are constantly reminded that strings are arrays, LV blurs the distinction, but fundamentally strings are byte arrays and have the same caveats.

 

In this case, my intuition tells me you are not going to have a major problem as long as you are not too sloppy.  Keeping War and Peace on your front panel will not be useful to anybody so I don't think you will be taxing the memory that way.  A long-running program could build up a large string, but in this case if you weren't also writing to a log file I'd consider you crazy.   I usually strike a balance, keep a reasonable length history on the FP, but if a user needs to dig into the archives let them open the log file.

Message 2 of 6
(3,501 Views)

So you would suggest that I display the string on the FP and also log the string in a text file?  If I really need to have do concat in a loop, should I initialize a long empty string then?  If I run into a situation where memory would be a concern, should I just use the same method that fix build array memory problem?

 

Yik

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 3 of 6
(3,465 Views)
Are you often building up enormous strings in time-critical loops?  If not, then don't worry about it.  If you have a loop that runs once a second and adds a few characters each time, it may not be worth making it more efficient.  Just don't let that string grow to thousands of characters.  It's good to be aware of inefficient memory use, but don't get carried away optimizing every portion of your program.
0 Kudos
Message 4 of 6
(3,455 Views)
I don't know what it is that you're logging, but an alternative is to use a queue of strings. Each queue element would be a line of text. The queue can be fixed-size, so at least it won't grow indefinitely. However, the individual elements can. But, if you are reasonable with your strings then this should not cause an issue.
0 Kudos
Message 5 of 6
(3,450 Views)

jyang72211 wrote:

So you would suggest that I display the string on the FP and also log the string in a text file?  If I really need to have do concat in a loop, should I initialize a long empty string then?  If I run into a situation where memory would be a concern, should I just use the same method that fix build array memory problem?

 

Yik


Personally, I use a log file and often put a button on the FP that will open it automatically.  You seem to want a FP indicator, which is totally legitimate, if you think easy access to the (recent) information is useful.  I still suggest a log file because you never can tell when Bill Gates will decide that your computer (or the user's) needs to be rebooted or that the power will go out. 

 

0 Kudos
Message 6 of 6
(3,442 Views)