LabVIEW
Trim Whitespace.vi is not re-entrant. Why?
@mcduff wrote:
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.
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.
Well fundamentally the OGTK does a different white space definition than the NI version. This is why benchmarking gets into a rabbit hole of possibilities. The benchmark statistics change significantly for large strings compared to small strings, again that rabbit hole diverges. End the end we end up says that that implementation is the fastest for that implementation. 🙂
The string I used for white space definition is the default LV system one.
Yes, there is a flaw in the first mod OGTK with an completely blank string. Will be fixed and tested. BTW, of course a subroutine priority VI locks up the entire LV PDS when it has an infinite loop and cannot be aborted by another VI. This causes a force quite of the entire development system... 😞
Thanks for getting back to the original topic. Yes, I can set that utility VI to reentrant and see if I notice any effects. But that is sort of a brute force test that can either leave hidden errors or is a pain to "fix" each installation of LV to be optimal. I already have to run a utility for each installation to fix up the wonky file security settings.
And to beat the dead horse a bit more since we got way OT on performance. I have compared all 7 versions. As pointed out the benchmark is testing 3 different functionalities (+1 for the Pink Floyd reference!!!). All 7 versions give the same results since I limited the white space to a subset of either the lexical LV definition or the lower 32 ascii codes.
As you can see the second modification for LARGE strings (order of megabytes) gives the best time at about 1 microsecond per iteration. (Mac OS X, core i7 4GHz CPU). And WMN comes a close second and about the same as the OGTK.
Now for smaller more reasonable strings on the order of bytes. Then Jeff's is clearly the winner (again testing for something different. But WMN comes close.
Attached is final(?) version of the comparison code. The answer is depending on your need different functions with different inputs have different timing. This is sort of why I dissed benchmarking the code in the first place.
Of course I still didn't get much info on performance of parallel code and memory usage but speed tweaks. I think that my issue with simultaneous code causing jerky performance may have to do with VISA locking/unlocking actually being not smooth and not for single resources as it should be. MUCH harder to test and benchmark than simple code like this.
I might have, but again, it is a different function. Significantly. This is the problem with benchmarks, testing apples to oranges never give you a nice pair.
