closed review Trim Whitespace (String Package)

[jaegen]

  On 8/24/2011 at 11:12 AM, Phillip Brooks said:

Just a quick observation. Does this design trade memory for speed?

If so, would this function ever be used in a memory constrained environment such as RT or FieldPoint?

It appears that two copies of the string data (as U8 arrays, one reversed) are created to iterate over. Is the LabVIEW compiler is smart enough to only use one buffer for the U8 array data? What does LabVIEW Profiler tell us about the buffer allocations?

I don't have 2009 installed, so I can't play with the examples.

If there are two buffer allocations for the U8 array data, would there any difference in performance if the 'end trim' loop were to use the same U8 array and simply index from the end of the array (N-i-1) until a hit was found?

I was curious about buffer allocations for the reversed array too. One of the things I tried was to force sequencing of the two case structures, rather than having them run in parallel, but nothing I did had any effect on the speed, even with a very long test string. However, if you pop up the buffer allocations display tool it does show a dot on the output of the reverse array node. I never looked into profiling memory usage.

I also tried iterating backwards from the end of the array, but this was significantly slower than just reversing the array and autoindexing.

I'd say all of this is probably moot though - RT and FieldPoint applications are very unlikely to be doing a lot of text processing, and if anyone is working with a long enough string to matter they should probably be doing something more customized to keep memory copies down.

Jaegen

[jgcode]

  On 8/24/2011 at 4:29 PM, jaegen said:

I was curious about buffer allocations for the reversed array too. One of the things I tried was to force sequencing of the two case structures, rather than having them run in parallel, but nothing I did had any effect on the speed, even with a very long test string.

I think is due to the subroutine priority setting - the loops must not be able to run in parallel, therefore the VI is as currently as fast as we can make it (it acts the same as if those loops were run serially).

Therefore, if memory is an issue, I challenge anyone out there to optimise it but retain speed

[jaegen]

  On 8/25/2011 at 12:58 AM, jgcode said:

I think is due to the subroutine priority setting - the loops must not be able to run in parallel, therefore the VI is as currently as fast as we can make it (it acts the same as if those loops were run serially).

Yeah, I figured the loop iterations were already running as fast as possible (with your standard test string, there are only 8 iterations total anyways right?). I'd forgotten/not noticed that the VI was set to subroutine priority.

  On 8/25/2011 at 12:58 AM, jgcode said:

Therefore, if memory is an issue, I challenge anyone out there to optimise it but retain speed

My suggestion above about chopping the boolean array saves a huge 224 bytes!

Edited August 25, 2011 by jaegen

[jgcode]

...Every bit counts ...lol

  On 8/24/2011 at 2:33 PM, Cloedu72 said:

What about using the Inline functionality?

Hi Claude

Thanks for the feedback.

Unfortunately, the OpenG codebase is in LabVIEW 2009.

Inlining was not exposed until LabVIEW 2010.

This is something we could discuss when we upgrade in the future, except for in this case the Execution Priority would be ignored, and that is responsible for the speed enhancements (along with some brilliant coding from the LAVA guys)!

Cheers

-JG

[jgcode]

I am going to go ahead and lock this topic.

I am leaning towards jaegen regarding the excessive use of strings (e.g. use non-contiguous memory allocations) on RT and whether it is an issue.

However, if anyone in the future thinks otherwise, and wants to post, please do and we can also integrate the code

I am really impressed by the outcome of this process.

I think the community has put together a very nice piece of code:

This VI will be in the upcoming String Package release.

Also look out for the next review!

Thank you very much for taking part.

Cheers

-JG

[jgcode]

This OpenG Review is now closed. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread.

Review Summary

Trim Whitespace (String).viFetching info...

Code is in LabVIEW 2009

[jgcode]

You can track the upgrade for this VI here: ID: 3292424