LabVIEW
Trim Whitespace.vi is not re-entrant. Why?
These are all great, interesting solutions. Just curious has anyone bench marked? I do not have the time now to try.
Just some random ramblings:
Even without reverse array there should still be a buffer copy, you are branching the original string wire.
@sth - Try your solution with a conditional for loop, read that for loops are usually faster than while loops somewhere, do not know if it is still true.
Attached is another solution, inspired by the ones posted here, that tries, probably unsuccessfully, to do everything in place. may work well for long strings, but probably slower for short strings.
Cheers,
mcduff
@RavensFan wrote:
@sth wrote:
Such as...
Why is your integer wire a lighter shade of blue?
Alternate wire colors. Tools options environment. Not a default ini option.
@mcduff wrote:
These are all great, interesting solutions. Just curious has anyone bench marked? I do not have the time now to try.
Just some random ramblings:
Even without reverse array there should still be a buffer copy, you are branching the original string wire.
@sth - Try your solution with a conditional for loop, read that for loops are usually faster than while loops somewhere, do not know if it is still true.
@mcduff...
Just because a wire forks does not mean that the data is copied. That has changed since long long ago. The compiler delays deciding on a buffer copy until one of the forks modifies the data. In this case I just count white space and there is no need for a buffer copy. You can turn on highlighting of buffer copies to check this.
For loops were faster when the output was an array. In this case they could pre-allocate an array instead of creating an array and having to allocate more memory and copy occasionally. Since I don't have an auto-indexing output this should not be an issue.
Again, speed is not really an issue since one is usually cleaning up a command string for parsing. There are usually not 1 MB strings with 200K of white space. It can happen but that is probably not what one should optimize for. Minimizing buffer copies is probably the best optimization for the use cases. If someone wants to bench mark this, go ahead.
The problem with single threading is possibly still my issue.
@RavensFan wrote:
And why would anyone want to change the wire colors?
Because the garish fisher price primary colors are aesthetically equivalent to poking a fork in your eyes. I hate to start a really old flame thread, but windows users seem immune to this assault on the senses. Sort of being hit over the head lessons. It was really nice when LV moved from B&W to color but we have moved beyond the need for a 4 bit color LUT and can actually use the full capabilities of modern displays and processors to make things ergonomic and less fatiguing. As a Mac user, design matters.
@McDuff, two things about your design.
1. You lose the parallelism by doing both loops serially. I haven't used a single core machine since about 2000. I usually boost the threads per execution engine to 8 (the maximum allowed in the configuration VI). The beauty of LV is to be able to write parallel code in an understandable, readable, maintainable way. Forcing serialism is a "bad habit" from text based languages.
2. You may lose some speed by using shift registers which has to make the output array back to the input as it loops. Not sure about the internals of that. It may be some copies or conditionals required for this.
