memory de-allocation string arrays

[belgron]

---

@altenbach wrote:

---

belgron wrote:

I was looking for an inplace way to avoid the delete from arrays, but didn't see an "elegant" solution (I assumed, maybe incorrectly, that indexing single element by element in an inplace structure would take a long long time with ~12000 rows and ~1000 columns).

---

Delete from array is an extremely wasteful operation and should never be used in a loop. Every "delete from array operation" needs to delete the portion, shift all remaining elements down by the size of the deleted portion, and resize the array to the new size. If you use delete from array N times, the last element in the array has been touched and moved around N times! In an in-place solution, the last element is touched only once. A difference by many orders of magnitude for large arrays. Remember that arrays need to be contiguous in memory.

Can you explain how you want to process the 2D array? What's up with the 10 strings that you are also converting to DBL (seems useless).

Whatever you are doing seems to use way too much code and is way too inefficient!

So, we have:

1. an array with 10 strings (SA, SB, SC, SD, SE...)
2. A 2D array with 12 columns and 500 rows A1, A2, A3...A12 /B1, B2, B3...B12/C1, C2, C3, ...C12/ etc.
3. A 1D array with 12 elements (X1, .. X12)
4. 1&3 gets concatenated to form a 1D array of 22 elements.

How should all this be arranged in the single output array? Can you show me the pattern using the above nomenclature?

---

I'm afraid this is a case of not seeing the forest for the trees. This was just a quick and dirty convert of a process (it wasn't important what it was) to demonstrate that in one case, deallocate memory works (the version with doubles - I only converted the string to doubles to keep the structure of the code between the two versions as close as possible), and in the other (strings) it does not.

Again, it's not really the point, but this was a case of a number of columns setup to work as a text file so it could be readable in notepad, excel, origin, whatever.

To answer the question, though:

1. Array with 10 strings SA..SJ which are header descriptors that are in the first column of the save file at the top of the X axis if you are graphing data

2. A 1D Array with 1000-12000+ elements X1-XN that constitutes the X axis that (in the save file) appears in the same column as the header descriptors (1 and 2 concatenated in the save file)

3. A 2D Array with N columns and the same number of rows as 1 and 2 concatenated (It contains 10 rows of header info and then same number of rows as 2 in experimental data)

X is in one array prior to saving in the text file, and the Ys are stored in a 2D array. All the code was doing was combing the two and preparing it for saving. In messing around with code, this particular example demonstrated the de-allocation problems with strings vs doubles (by being poorly written and wasteful in memory usage).

I appreciate the info on delete from array and will try to avoid using it in loop situations in the future (and will post nicer code as examples, consider me castigated).

Anyway, hopefully if this is a bug, and the string arrays are not being deallocated properly, this brings it to someone's attention. If it's as the other user suggested, that the memory is being flagged but is not being cleared for some other reason, then at least I have a possible answer as to why the two are behaving differently.

[AustinPeter]

Hello Belgron,

I was just wandering if you managed to solve this? I am having the exact same problem when working with 2D Arrays and it is driving me crazy. Same thing that although i even have a de-allocation VI i am still finding that i have memory left in storage even once I shut down the VI, it is only when i shut down labview that the memory finally goes away. I am also working with reasonably large text files 20Mb plus and manipulating the data. People keep to offering solve my algorithms but it is the memory issues that i need removing. Just wandering how you got on?

Best regards

Peter

[altenbach]

---

AustinConsultants wrote:

I was just wandering if you managed to solve this? I am having the exact same problem when working with 2D Arrays and it is driving me crazy. Same thing that although i even have a de-allocation VI i am still finding that i have memory left in storage even once I shut down the VI, it is only when i shut down labview that the memory finally goes away. I am also working with reasonably large text files 20Mb plus and manipulating the data. People keep to offering solve my algorithms but it is the memory issues that i need removing. Just wandering how you got on?

---

I guess you are probably talking about this old discussion. Did you ever streamline the code according to my suggestions? I think your main memory issue is due to your wasteful and overly complicated algorithms. In any case, we cannot really troubleshoot that other problem because we don't have any of the subVIs.

[AustinPeter]

Hello,

Just to add to this, Altenbach I genuilly really appreciated the help and did fix some of the efficiency of the algorithms used but we proved that LabVIEW 2012 and 2013 have a memory bug when it comes to maniplulating 2D string arrays which don't happen with 2D numeric and others. To solve this, what you can do is just as soon as you have used the 2D and grabbed a function, immediately use a local variablet to reset the initial 2D array or subset that you are using to a bland value. that way it will limit the amount of memory you have in the VI as it will not get shut down otherwise. so any inputs are blank by the time the vi finihsed. That should allow simple tasks to be completed without having to spend too much time thinking about the best way to create the algorithm to be most efficient which when prototyping and might be scrapped in the future wasn't saving me time 🙂

Hope that helps any one else stuck with this issue!

Pete