Trim Whitespace.vi is not re-entrant. Why?

[mcduff]

Update:

Jeff's solution is almost as fast as the Open G, hardly any difference.

The modified OpenG solution seem to get stuck in their while loops for some reason, since debugging is off I cannot see the string that is causing it.

mcduff

[mcduff]

@sth

The modified OpenG functions will run infinitely if the string input is ALL white space, like

\n\n\s\r. They should be modified to handle this case.

[mcduff]

<edit>

It's Trim Whitespace (String)__sth, that has the while loops that will run non-stop if fed a string with only white spaces.

Sorry for the mix-up.

[JÞB]

---

@mcduff wrote:

Update:

Jeff's solution is almost as fast as the Open G, hardly any difference.

The modified OpenG solution seem to get stuck in their while loops for some reason, since debugging is off I cannot see the string that is causing it.

mcduff

---

Let me mak it clear at this point.  NONE of the three  vi's do the same thing

Shipping Trim Whitespace.vi trims some whitespace [\n\r\l\s]

OpenG Trim Whitespace.vi trims anything of "Lexical class" Whitespace" [horizontal tabs, vertical tabs,form feed ,newline, carriage return, BEL, and space] Yes the whole set of Whitespace characters- Trim Whitespace.vi  (Shipping) is flawed! because it does not trim white space (just 4/7th of them)  

The other 3/7th of them you cannot type without pressing alt and entering 4 digits from a number pad.

Trim String.vi does not care about Lexical class it just tosses out "Garbage" Characters.

Compering Apples, Oranges and Pairs. is probably a Bad Bad Bad idea!

• Use Apples when you want Apples
• Use Oranges when you want Oranges
• Sometimes you want a Pair

[WNM]

---

@JÞB wrote:

Compering Apples, Oranges and Pairs. is probably a Bad Bad Bad idea!

• Use Apples when you want Apples
• Use Oranges when you want Oranges
• Sometimes you want a Pair

---

I believe, in the context of apples and oranges, you meant to say PEAR but I also agree that, as you [and Pink Floyd] have suggested, sometimes "you want a [nice] Pair".

In the context of this discussion however, I do wish before it's wrapped up someone summarizes the findings with a best-in-class trim string VI either in the form of a snippet, code image or VI that's in a version earlier than v16.  I've attached what I've been using.

[sth]

@cbutcher wrote:

However, the detailed help gives this for subroutine:

When a VI runs at the Subroutine priority level, it effectively takes control of the thread in which it is running, and it runs in the same thread as its caller. No other VI can run in that thread until the subroutine VI finishes running, even if the other VI is at the Subroutine priority level. In single-threaded applications, no other VI runs. In execution systems, the thread running the subroutine does not handle other VIs, but the second thread of the execution system, along with other execution systems, can continue to run VIs.

Note that threads are allocated separately for each of the 5 execution systems and for the 5 priorities (look at threadconfig.vi).  There is no thread allocation for Subroutine.  Just background, normal, high, above normal, time critical. 

The documentation seems to imply that a "Subroutine Priority" VI when called by a Background priority caller, locks that background priority thread, to that subvi?   So it basically grabs an existing lower priority thread in some execution engine and locks it to that VI.

Back to the original question.  Why would one want to do that kind of high priority locking for a simple string manipulation?  Is the scheduling algorithm that bad that it can't handle scheduling a lot of tasks on the run list and managing threads efficiently that one has to to single thread all of LV?  Why are simple utilities not reentrant.

[sth]

I'll even ask another weird question.  Why is there still a choice of reentrant vs. non-reentrant code once you have selected in-line coding option for the sub-vi???  What is the meaning of reentrant in-line code?

If you incorporate the subroutine into the calling routine, then that code is not a separate procedure that can be made reentrant.

Yes, I changed my VIs for calling the same set of strings.  I did not keep all generated strings first, but added up the times for each option after generating each string.

[altenbach]

---

@sth wrote:

I'll even ask another weird question.  Why is there still a choice of reentrant vs. non-reentrant code once you have selected in-line coding option for the sub-vi???  What is the meaning of reentrant in-line code?

---

There is no choice. Once inlined, you break if you make it not re-entrant. I agree that the configuration page could have been designed differently, e.g. by greying out (and ignoring) more entries for certain settings.

While the help page still says that the subVI must be "preallocate clone reentrant", "a setting of "shared clone reentrant" seems to be allowed for inlined subVI.

[sth]

What is the underlying nature of reentrant in-lined code?  In-lined code becomes part of the calling VI and is no longer a sub-vi.  As such the calling VI is either re-entrant or not reentrant depending on its settings.  Once you declare a VI as in-line then all choices of reentrant/non-reentrant/debugging etc. are ignored.  (unless the NI compiler team can show me otherwise.)

For in-line the subvi not only clones the data space but makes a copy of the instruction space in the caller.  So it is an effective preallocate of the data space but not the same as a preallocated clone.

[mcduff]

This is hopefully my last post on this topic, I have spent too much time pondering white spaces.

The last benchmark I did was with LabVIEW 2017 64 bit, Windows 7, 4-core Xenon processor. All Trim White Space subVIs were set to subroutine priority, debugging off in the calling VI.

I did not include the 2 modified OpenG VIs as one could get caught in an infinite loop and the other gave a different result with respect to the other VIs. For short strings, WNM's solution was the fastest.

For longer strings, Jeff's solution was the fastest

Note, there is some weird effects with regard to the order of the tests, that is, the times can change slightly. No idea why.

@Jeff

I'll use a car analogy rather than a fruit analogy. Sometimes, I need a Jeep, other times a Porsche, other times a Prius. On rare occasions I may need a semi. Rather than compare only SUVs lets look at some different models and see what works best for our use case.

@sth

Why are simple utilities not reentrant.

AQ answered this a while ago for the trim white space case. Whether that answer is still valid is another question. My suggestion to you is to follow Jeff's earlier advice, with the following caveat. Copy the original Trim Whitespace VI to your desktop. Go into LabVIEW and change it to reentrant. If LabVIEW becomes hosed, unstable, etc, close LabVIEW and replace your modified version with the original one on the desktop.

mcduff out (mic drop)