[Discuss] Fast Trim

[ShaunR]

Name: Fast Trim

Submitter: ShaunR

Submitted: 03 Jan 2011

File Updated: 16 Jan 2011

Category: *Uncertified*

LabVIEW Version: 2009

License Type: BSD (Most common)

Just an alternative to the in-built "Trim whitespace.vi" function but much faster (3x?).

It's not a direct replacement (although it could be) since it does not allow left and right trim separately. But it does allow trimming of all non-printable characters as well as whitespace if required (default is just whitepace).

It's an offshoot from one of my projects that I thought may be of interest to the speed freaks out there.

Click here to download this file

[ShaunR]

BUG !!!!

Anyone spotted it yet?

[vugie]

Does it trim whitespace and everything else as well?

[Yair]

I didn't look at the code, only the screenshot, but to expand on vugie's answer:

1. If there's no leading or trailing white space, I believe it will keep going until it finds the first WS and trim the text before/after it as well.
2. If there is no WS at all, I believe it will trim the entire string.

[ShaunR]

Does it trim whitespace and everything else as well?

Nope.

It works fine, but for 1 edge case.

I didn't look at the code, only the screenshot, but to expand on vugie's answer:

1. If there's no leading or trailing white space, I believe it will keep going until it finds the first WS and trim the text before/after it as well.
2. If there is no WS at all, I believe it will trim the entire string.

The function doesn't detect whites-paces, rather it detects non-white-spaces.

1. It will stop at the first and last non white-space. So it will return the string at offset 0 of length = length and never gets to see any within the string.
2. If there are no white-spaces at all then it will halt at offset=0 and length will equal length (length - 0 - 0) so it will return the entire string

Are we bored yet

[Yair]

The function doesn't detect whites-paces, rather it detects non-white-spaces.

You're right. I didn't look closely enough at the code inside the loop and I flipped its logic. It happens to me sometimes.

Are we bored yet

Yes. Hunting edge cases is not what I would consider a fun activity in my current state.

[jgcode]

Shaun, if you were interested, this VI would be a great addition to OpenG. I will contact you offline to follow up.

[ShaunR]

You're right. I didn't look closely enough at the code inside the loop and I flipped its logic. It happens to me sometimes.

Yes. Hunting edge cases is not what I would consider a fun activity in my current state.

OK. enough is enough eh? I've uploaded the fixed version.

Shaun, if you were interested, this VI would be a great addition to OpenG. I will contact you offline to follow up.

Knock yerself out. Do I get a fee package manager professional

[jgcode]

No, but you can have a free VIPM Community Edition

[ShaunR]

Shaun, if you were interested, this VI would be a great addition to OpenG. I will contact you offline to follow up.

If it needs to be a direct replacement for the normal trim. Here she is......

[Phillip Brooks]

My libraries have something similar for trimming, but use the lexical class as an input.

[ShaunR]

My libraries have something similar for trimming, but use the lexical class as an input.

That's sweet. I like the idea of using the lexical class. How do you trim both ends? Use twice? You could use an enum to choose head/tail or both.

The speed of my implementation derives from the fact you do both ends at the same time and you don't have to increment along the entire string. So the speed doesn't deteriorate with increasing string size (assuming the reverse string and array aren't a factor....which they don't seem to be).

But it's a bit moot since we both have difficulty testing our implementations without resorting to ridiculous string sizes and/or improbable numbers of iterations. But I love these sorts of little nuggets of re-inventing the wheel - only a little rounder and a little more grease.

[Phillip Brooks]

That's sweet. I like the idea of using the lexical class. How do you trim both ends? Use twice? You could use an enum to choose head/tail or both.

Yeah, there is a higher level VI that calls this twice. My main point for sharing it was the lexical class idea. This VI is from 10+ years ago; I've used it a couple of times recently, but never looked at it for performance. Any time I see an array of constants on the BD, I think that this can be done a better (more extensible) way...

[gb119]

That's sweet. I like the idea of using the lexical class. How do you trim both ends? Use twice? You could use an enum to choose head/tail or both.

The speed of my implementation derives from the fact you do both ends at the same time and you don't have to increment along the entire string. So the speed doesn't deteriorate with increasing string size (assuming the reverse string and array aren't a factor....which they don't seem to be).

But it's a bit moot since we both have difficulty testing our implementations without resorting to ridiculous string sizes and/or improbable numbers of iterations. But I love these sorts of little nuggets of re-inventing the wheel - only a little rounder and a little more grease.

I found this quite interesting. I had a go at making a version that avoided the array reverse to try and stop allocating additional buffers for the string by indexing from both ends in the same loop. The result was slower (by about 10% or so) that this version. This was on both 8.6.1 and 10. I'm guessing that the extra overhead of reversing the array is worth it to let the two loops indexing each end run truly independently (my version also had some overhead to handle the - common - situation of unequal amounts of white space at end of the string). The really impressive thing was how much faster both versions were than the regular expression based one - for my tests it was an order of magnitude for short strings and more than that for 4k strings. I've attached my slower version (8.6.1) in case anyone is interested enough to spot if I've done something stupid.GB String Trim.vi