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

[sth]

The "Trim Whitespace.vi" is a very useful utility and gets sprinkled all over a project.  It can be called from various simultaneous parts of a project as well as from independent top level VIs.  As such I would think that it should be re-entrant?

I have been seeing choppy response from two different simultaneous top level VIs and one of the shared sub-VIs is "trim whitespace".

This seems to just be a configuration oversight?  This utility seems to have been written long ago (~ 2002) and has been blocking execution ever since.  I have lots of CPU cores and forcing single threading seems to be unnecessary here.

[cbutcher]

Is it faster/smoother if you make it re-entrant? At least in 2017 there's no reason I can see that you couldn't do that, although I guess that isn't the point of the question...

[GerdW]

Hi sth,

strings are unlimited in size: using TrimWhitespace in parallel might result in huge memory consumption...

The compiler will also optimize this function to remove the different case structures inside for the op mode...

[mcduff]

I remember reading either here or on lavag.org that the trim whitespace is used all over the place that making it re-entrant would cause LabVIEW to run out of memory, this was from AQ. If you need to use it in a tight loop then roll your own or use the primitives. The snapshot is from the Error Cluster From Error Code.vi, these are NI's comments.

mcduff

[JÞB]

I've never really understood what the difference is that makes Match Pattern improve performance over a regex match.  I suspect there is a caveat or two that we are missing in the help file.

Frankly, Trim Whitespace.vi could be improved with some code I serendipitous wrote yesterday for a similar problem.

So, Why not?

[cbutcher]

So the point is that all of the lowest 33 ascii character codes are trimmed? With 33 being the first non-whitespace character? 

Is that the same behaviour as the trim whitespace VI?

[JÞB]

---

@cbutcher wrote:

So the point is that all of the lowest 33 ascii character codes are trimmed? With 33 being the first non-whitespace character? 

Is that the same behaviour as the trim whitespace VI?

---

NO! Trim Whitespace.vi only searches ^[\t\n\r\s] and [\t\n\r\s]$  Trim String.vi attached throws out everything below "!" Other than that caveat they are very similar

[mcduff]

@Jeff

Works nicely! I will wait before I test it to see if Altenbach posts a faster solution.

mcduff

[altenbach]

---

mcduff wrote:

Works nicely! I will wait before I test it to see if Altenbach posts a faster solution.

---

Nah, I am more of a "numbers" kind of guy. 😄

[ben64]

---

@altenbach wrote:

---

mcduff wrote:

Works nicely! I will wait before I test it to see if Altenbach posts a faster solution.

---

Nah, I am more of a "numbers" kind of guy. 😄

---

A "complex" guy 😄