LabVIEW
Trim Whitespace.vi is not re-entrant. Why?
@sth wrote:
Why this should be a big hit in performance either preallocated or shared is my question.
It's the strings that needs new buffers, and if they all do it at the same time (some 100+ instances was mentioned) it can be a memory hog while working. However, if the requirement to use Shared reentrancy is non-subroutine, i'd say it's okay to lower it to Time Critical. 🙂
/Y
@drjdpowell wrote:
@sth wrote:
@drjdpowell wrote:
Original conversation on OpenG Trim Whitespace.
That conversation was entirely on speed and not memory. My guess is removing the reverse array will contribute to both but only noticeable for long strings.
Why are you “guessing”? You should be testing. Personally, I would not expect “Reverse Array” to cost anything, as that primitive doesn’t actually reverse the bytes in memory (it just marks which end to index from).
Yes, but implementing a good testing program for each small issue is a time consuming project and takes away from the idea of getting things done. Actually more information about the LV internals makes things more transparent and testing can be just a time consuming reverse engineering exercise. As you know, a simple benchmark is easy but doesn't tell you what you want to know, a complex benchmark that really tests the cases you need is a bigger undertaking.
BTW: The reverse array primitive shows a "buffer allocation" for the reverse array operation on the byte array in the OGTK version of trim white space. Right there, that should make me "guess" that there is a performance hit.
Lastly, there seems to be a confusion about the shared clone / pre-allocated clone memory handling. All the clones share instruction space so the length of code does not matter (or only 1 copy). HOWEVER the difference is if the data space for the VI is allocated at compile time in the caller or at run time in the VI itself.
BUT, this is not true for strings and arrays! There is no string memory preallocated for buffers in either type of reentrant VI. There cannot be since the VI can handle any length string. The handle (i.e. pointer) to the string on the heap is passed to the reentrant VI. The memory for that handle is pre allocated NOT the string itself. It is unknown how much memory to preallocate for an unknown length string.
The Trim Whitespace VI has to make at least one buffer copy from the input to the output which is a different string. In my implementation that is in the "String Subset" operation. All other buffer allocations are of small scalars. In the OGTK version there are 2 allocations in the reverse array and the array subset operation. In the NI version there are FOUR! allocations one each in the match string primitive and one at the boundary of each of the case statements.
If you are passing large strings then the allocations add up in reentrant VIs that can use the memory simultaneously. By non-reentrant use one is merely using the same memory but allocating and reallocating it as necessary for each sequential call.
sth wrote:
BTW: The reverse array primitive shows a "buffer allocation" for the reverse array operation on the byte array in the OGTK version of trim white space. Right there, that should make me "guess" that there is a performance hit.
Another reason why "copy dots" is a bad name for "buffer allocations"
@mcduff wrote:
Works nicely! I will wait before I test it to see if Altenbach posts a faster solution.
mcduff
Just because you asked
I modified The test bench from the OpenG link
So, in the cases where you do not mind trimming more than whitespace, Use Trim String
Let me make that FP shot a bit larger
In sth's use case (cleaning up VISA Strings) the result might be better anyway (Gets rid of control codes too)
@Jeff
Nice!!
Ironically enough, I have having the same conversation, DrJ was there also, about the trim whitespace with respect to the JKI State machine on GitHub. I may have to try your solution. One thing that DrJ noticed was that if there is good chance of having an empty string, then having a case structure was much faster, this was true for the Match String Case. However the case structure needed to look like this, string wired directly to case structure:
I was a bit worried about large string performance
NOTE: The native Trim Whitespace.vi just could not play with the others and I had to unload the loop count 1000:1 to make it finish in a reasonable time. OGTK loses some performance as expected but Trim String.vi is essentially un-affected. I suspect there is a very smart search in the Threshhold 1D array.
