Are "String to Byte Array" and its twin "Byte Array to String" in-place (memory) operations? (or do they incur copy/memory operation penalty?)

[QFang]

I can't seem to deduce the answer to this question (post subject/title) from the LabVIEW Help on the function(s).  

Intuitively, it seems like both data representations are equal in memory and so going between the two should essentially be a no-op once the code compiles... but is it? (assuming length of string/array remains constant, can I go back and forth repeatedly without performance overhead?)

Since a LabVIEW string is a handle, and any other datatype except arrays are not a handle; that implies to me that a string-handle = U8-array-handle  and so a string to a U8-array could be an in-place memory operation or no-op since no conversions actually have to take place?

The reason I ask is that when working with e.g. TCP Read or VISA Read, the read 'data' is always a string, but depending on what you are doing, often that string is more efficiently handled/interpreted if converted to a U8 array, and I just want to know if (from memory and CPU point of view) I can freely move between string and U8 array and back depending on what format is most appropriate at any given time?

(Also, I'm at this point fairly certain that "String to Byte Array" is cleaner AND more efficient than a strin type-cast to a U8 array.. but I could be wrong.)

[Bob_Schor]

This is not meant as The Definitive Answer, but as A Logical Answer.  When you start with a String of, say, 1000 characters, you have memory somewhere with 1000 bytes tucked away.  When you do a String to Byte Array, you have an additional Byte Array of 1000 Bytes.  Both exist at the same time.  If you increment the third Byte in the Byte Array, the String will remain unchanged.

Hence, logic dictates that this operation (and its inverse) allocate data storage necessary for the newly-created Data Structure.

Bob Schor

[mcduff]

I believe they are in-place. (I remeber when checking memory on Windows systems) Type-Cast always makes a copy.

Another memory tip, if you are saving to binary file. Let the primitive file VI do the conversion, that is, do not type-cast first.

Cheers,

mcduff

[mcduff]

As you say do the experiment. I'll willing to bet a beer that no additional memory is needed. (I did this experiment in 2012, assume the same for later versions.)

Cheers,

mcduff

[nathand · Accepted solution]

I did some testing on this a while back and my conclusion was that this is absolutely in-place. The local user group had a coding challenge where that became relevant to my solution.

[QFang]

Hi Bob_Schor,  your logic applies if I branch either the string input wire or the array output wire, otherwise there is no reason it could not be all pointing to the same data-space. 🙂

And to the rest of you guys, thanks for confirming (to within reasonable doubt) my suspicion.  Contrary to what I normally do, I don't think I will try to explicitly test this scenario myself, and even if I tried, I would likely question and doubt my testing methodology and end up back here on the forum anyway! 🙂

[nathand]

Bob - LabVIEW stores a string and an array of bytes identically in memory (a 32-bit value for the length, and the actual data) so there's no need for the string and array to exist separately, at least until you modify one of them. In your example where you increment one array element, the array copy happens when you insert the new value into the array, NOT when you convert the array to a string (and even then, most likely a copy happens only if the unmodified string is still needed elsewhere).

[Bob_Schor]

Lay on, McDuff.  Almost hoist by my own petard!

I did the following (in LabVIEW 2015):

This has a Data Space of 10.8K (reasonable) and a total space of 29.2K.  I then deleted the array, added a Byte Array-to-String, and added a String Constant.  Data Space of 10.8K, total space of 37.5K.  Hmm.  I deleted the two changes, and went back to the U8 array.  Data Space of 10.8K, total space of 46.2K!  Someone is not garbage-collecting.

OK, do it again with "fresh VIs".

                 Bytes             String

FPO           6.0K              10.4K

BDO          9.6K              14.6K

Code        2.8K                 2.9K

Data       10.8K               10.8K

Total       29.2K               38.7K

Note that if you have the temerity to try this with a Diagram Disable to choose between the options, your Data size will double!

So bottom line (as borne out by the Experiment) is that as long as it remains in the wire and you are only changing its representation (and not trying to use it independently in both format, i.e. "don't fork with me"), the data memory is not changed.

[I need that fork, however, for my Humble Pie ...].

Bob Schor

[Bob_Schor]

McDuff, I owe you a beer.  You can collect at NI Week (send me a private message if you are going in 2016, we'll arrange to meet ...).

BS

[mcduff]

No hassles. I was just having some fun after a long night. I mainly do LabVIEW on the side as it is not primary function in my workplace. So Miller time will have to wait. 🙂

Cheers,

mcduff