mje Posted November 3, 2011 Report Share Posted November 3, 2011 Easy question: Are LabVIEW strings immutable? If I'm working with large strings, and changing individual characters in the string, does each operation force a new string to be allocated? Or does the compiler internally operate on the string like an array if the operation does not force a frame shift, length change, or what have you? Quote Link to comment
asbo Posted November 3, 2011 Report Share Posted November 3, 2011 It looks that way. I checked the buffer allocations on two different string functions I think shouldn't need to re-allocate the string, but both showed allocations. Quote Link to comment
mje Posted November 3, 2011 Author Report Share Posted November 3, 2011 Good point, although keep in mind the allocation dots only say a buffer might be allocated. Of course I can't think of a single case where reversing a string would ever not be able to operate in place, so I expect that it tells the compiler it might allocate, in reality it always does... Quote Link to comment
Aristos Queue Posted November 3, 2011 Report Share Posted November 3, 2011 LabVIEW strings are not immutable. The compiler does consolidate and modify. What have I repeatedly said? "Buffer allocation dot is not the same as a copy". A buffer allocation is a place where we can *hold onto* a string. Two string buffer allocations would mean that there are two strings, but we can modify one of them and just swap it into the next position, without making a copy. All LV data types are mutable and subject to this inplaceness analysis. For the special case of "reverse a string", we just set a flag on the string that says "this string should be traversed in reverse", so it is a constant time operation. Quote Link to comment
GregR Posted November 4, 2011 Report Share Posted November 4, 2011 Before someone times this and realizes it is not true. Although we have some internal support that could someday allow reverse string to be constant time, it is not. Reverse string will actually swap all the characters in the string. Reverse array on the other hand is a constant time operation. 1 Quote Link to comment
asbo Posted November 4, 2011 Report Share Posted November 4, 2011 LabVIEW strings are not immutable. The compiler does consolidate and modify. What have I repeatedly said? "Buffer allocation dot is not the same as a copy". A buffer allocation is a place where we can *hold onto* a string. Two string buffer allocations would mean that there are two strings, but we can modify one of them and just swap it into the next position, without making a copy. I hadn't heard that before, thanks for the clarification. Quote Link to comment
Aristos Queue Posted November 4, 2011 Report Share Posted November 4, 2011 Read all the documentation about "inplaceness" Before someone times this and realizes it is not true. Although we have some internal support that could someday allow reverse string to be constant time, it is not. Reverse string will actually swap all the characters in the string. Reverse array on the other hand is a constant time operation. My mistake. I thought they were both that way. Thanks, Greg. Quote Link to comment
BrentonLang Posted November 6, 2011 Report Share Posted November 6, 2011 Before someone times this and realizes it is not true. Although we have some internal support that could someday allow reverse string to be constant time, it is not. Reverse string will actually swap all the characters in the string. Reverse array on the other hand is a constant time operation. Is this also the case for ARM Development? As LabVIEW generates C code? Quote Link to comment
Wire Warrior Posted November 7, 2011 Report Share Posted November 7, 2011 Okay what is the "allocation dot" I have not heard of that before. Sounds like a good thing to know. Thanks jason Quote Link to comment
mje Posted November 7, 2011 Author Report Share Posted November 7, 2011 The little dots that appear on the diagram when you use the Tools > Profile > Show Buffer Allocations... option. Just be aware, that a buffer allocation doesn't mean that a copy will happen. It's ambiguous, I know, but it's all we got. Thanks for the info, AQ. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.