trim whitespace

[stbe]

The current version of Trim Whitespace.vi uses regular expressions that are quite slow, but not needed since only simple search and a substring function is desired.

Therefore, I suggest to throw out the regex functions and replace them with G code looking for the same whitespaces (or even extend the selection to the openG variant).

I use the presented version within all my string processing functions, but many shipped VIs (especially the NI_LVConfig.lvlib) uses the trimming functions a lot. Since I do a lot of config files, this starts to be the bottleneck of the total LV code.

left-trim sub-VI:

right-trim sub-VI:

Performance metrics suggest speedup of about a factor of 15 for short strings and even more (>35) for longer strings.

[altenbach]

> I am curious to see some meaningful benchmarks, perhaps I'll try.  It seems as the LV compiler gets more clever it gets harder to fool it.

I did the following:

(1) take the string length at the subVI ouput and sum it in a shift register in the inner and outer loop. (avoid dead code elimination).

(2) reverse the string for each odd iteration (now it depends in [i] and is no longer loop invariant).

Maybe more needs to be done....

[Darin.K]

So other than the fact that the Trim Whitespace.vi is not inlined automatically, and that the String Control can not be moved outside the For Loop, the Newsletter article was accurate.  At least they corrected half of it for the online version.

Sticking to LV9 for benchmarking I find that altenbach's modification using Lexical Class beats the built in VI by about a factor of 3 for larger strings.  A small modification to use the Whitespace? comparison directly nets another 30-50% improvement over that version.  Overall, a net gain of around 5X, but even the slowest times are measured in msec.

Both modifications require you to live with LV's definition of whitespace, one of the reasons why I keep using my own version.

[stbe]

altenbach: I'm sorry that I forget to mention that I enabled also subVI inlining for the shipped version of Trim Whitespace. (At least I indirectly made you file a bug report 🙂 ) However, not using the outputs (any more) as in the posted testbench is truely not a valid benchmark.

I had intermediate versions of the benchmark that used shift registers (see below) to feed back the output of the trimming functions to feed back the result in the next iteration (which even makes sense since most of the time nothing needs to be trimmed at all). That is also where I had my results from.

That I posted the version with tunnels most likely resulted from changing the shift registers to tunnels and collecting the results in an array (which of course caused LV to allocate huge amount of memory, got very slow and unresponsive and I killed the process).

Anyhow, what I tried to indicate was that often, using regex is something like to take a sledge-hammer to crack a nut. I mean, I really like regex, but I use them rarely when we can do simpler.