LabVIEW
Trim Whitespace.vi is not re-entrant. Why?
@drjdpowell wrote:
I had a play at benchmarking different ways to trim whitespace yesterday. Some comments:
— Be careful about being fooled by substrings. If you don’t actually use your strings in your test code then you may never convert substring to true string, and thus get really good speed numbers that will not translate into actual performance in the real world.
— Similarly, if you are inlining, either directly or via the inline option on a subVI, be careful about dead-code elimination. You must actually use your string, or the compiler will eliminate the trim entirely as “dead code” that does nothing.
— The poor performance of the native LabVIEW version with large strings seems to be due to the trim-from-back part. “Match Pattern” may not be optimized for looking a end-anchored patterns (ending in $).
I think I was careful about bringing my trimmed strings out of the test loop.. Could be optimized away, but I will pass them to a different SubVI in both test and blank case. but not sure what is happening in compiled code.
I have left the default setting for both the OGTK and vi.lib trim string. I have not done in-lining since that duplicates the code in every calling VI. It may allow for optimization but causes a huge ballooning of IS if the SubVI is called 150+ times. NI did not do it for their vi.lib version so I haven't gone there.
Third point, I agree. In looking at the memory profiler it seems the reverse array does not duplicate the array in the OGTK version. I think that it was LV version ??? that implemented sub ranges and reverse indexing as part of a handle pointing into the array data. It made the handles larger and indexing a bit slower but was a huge savings in data space.
I will post my benchmark code when I get into work today. Waiting for some home repair folks, but I think they are a no show due to rain. (Tropical storm later this week!)
As promised here is the benchmark code. But again, the issue is threading not ultimate performance.
Thanks for posting, haven't had a chance to play with it, but you do have an error. In this part
The string is not marked Codes Display, that is, you are not inserting White spaces like you think. Change that string to Codes Display and remove the extra backslashes.
Also why are you testing with such a long string, I thought your strings were much shorter.
Cheers,
mcduff
@mcduff wrote:
The string is not marked Codes Display, that is, you are not inserting White spaces like you think. Change that string to Codes Display and remove the extra backslashes.
Also why are you testing with such a long string, I thought your strings were much shorter.
#1 Doh!
#2 Stress testing....
@mcduff wrote:
Not a member but I long time reader, lavag has given me a server error whenever I try to go there. Is it only open for members?
Yes I think someone else replied. LAVA is open and free, but for some reason there is issues lately if you aren't logged in. You will see the page as incomplete. I've already contacted the site admin but haven't heard anything. In the mean time try to sign up to see the content.
Also neat thread.
Fixed string error. Also added another version which is about 20% faster than the OGTK version. All versions seem to use about the same amount of memory (according to the profiler). Between 2.5KB and 2.8kB. So spawning 200 versions simultaneously should only be 560kB IF they were all actually simultaneous or NOT preallocated clones.
But they would not be all simultaneous since there is only 1 thread at subroutine priority!!
So you would get memory savings and speed by changing to "High Priority" and changing to Shared Clone reentrant. In this case even if the routine was called 200 times it would only need to make copies of the data (1.8kB) for the number that happened to be exactly simultaneous (i.e. within the 2 or 3 microsecond window it takes to operate)
The instruction space is about 2.3kB and the data space about 1.8kB.
@Hoovah
Maybe I should sign up and join the lurker thread.
Look at the following screen shot. The case structures may add buffer copies and hence slower. Look below at see one less pair of dots when no case structures. This may be one reason why the native trim is slower.
@sth
If I use your new tester and turn debugging off for the tester, then if I place this directly in a case
it is about 100x faster than any other method, no case structures for removing from both sides and concurrent execution no problem. Try it.
mcduff
