LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Convert Hexadecimal String to Byte Array

Solved!
Go to solution

@DavidBoyd wrote:

I know this post has been marked answered, but I just can't help myself.


I guess for large strings your method might cause performance issues due to excessive memory reallocation because you grow an array at a while loop boundary where the final size cannot be determined and allocated beforehand. I am sure you could calculate the required number of iterations (from string lenght and initial offset, etc.) and use a FOR loop instead. Done correctly, you would not even need to delete from array afterwards. 😄


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 21 of 29
(1,421 Views)

Chris,

 

I think the efficiency of array build at while loop border has been discussed to death, and I take it for granted any more that the compiled code does a pretty good job of optimizing the number of reallocations.  I think there's some power-of-2 strategy going on for reallocs, and unless this is for really huge strings (or a coding challenge!) I'm willing to accept the performance results in favor of code readability.  (And I have a strong preference bias for Scan From String & Format Into String, over all the one-off nodes in the Number/String Conversion subpalette, probably from my C coding days of sscanf()  & sprintf(); also because they have error in and out terminals.)

 

I was really making my point about Vijay's (completely unnecessary) use of the SR on the string, which I think is a common novice mistake, where the string is potentially being recopied on every iteration (though I hope the compiler has gotten smarter than that).

 

Definitely wasn't trying to be critical of your accepted solution, which demonstrates how to compute iterations required (even OR odd length).

 

And besides, it gave Darin a chance to show off his Rube Goldberg skills Smiley Very Happy

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 22 of 29
(1,412 Views)

@DavidBoyd wrote:

(And I have a strong preference bias for Scan From String & Format Into String, over all the one-off nodes in the Number/String Conversion subpalette, probably from my C coding days of sscanf()  & sprintf(); also because they have error in and out terminals.)


Well, it is also the constant termination checking that requires resources. Of course if the string contains garbage characters (not 0..F), you would notice it earlier 😉

 

Here's more universal code. If you would change the representation to a multibyte type, you could even use higher strides.

 

 


@DavidBoyd wrote:

And besides, it gave Darin a chance to show off his Rube Goldberg skills Smiley Very Happy


Well, that was predictable :D. Just wait until I post my typecast solution 😮

 

 


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 23 of 29
(1,402 Views)

Some casual testing shows my original solution ot be about 3x faster. That is significant.

 

The two versions using scan from string (your while and my FOR loop) are very similar but clearly slower.

 

For 2M hex characters: my original: 150ms, versus 430ms and 440ms(yours).


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 24 of 29
(1,391 Views)

I do not Type Cast in these situations because of the potential for odd lengths, but I do this sometimes:

 

HexStringToBytes_v2.png

 

With a somewhat larger LUT I could remove the To Upper Case function.

0 Kudos
Message 25 of 29
(1,379 Views)

@Darin.K wrote:

I do not Type Cast in these situations because of the potential for odd lengths, but I do this sometimes:


Yup, that's another 8x faster (~20ms for a 2M String) 😄


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 26 of 29
(1,375 Views)

Chris,

 

I'm stumped as to why the Scan From String performance is so much poorer than the String Subset->Hexadecimal String To Number duo.  I figured SFS to be a pretty direct knockoff of sscanf and so, optimized about as much as possible over the years.  Maybe it's the error output processing?  But then, your for loop example using SFS doesn't wire the error out, so I would expect that handling to be skipped.

 

Also, when I re-created your SS->HStN example in LV2013SP1, the output of String Subset shows a buffer allocation dot, and floating help doesn't identify it as a (sub)string.  This seems odd to me.  Does this really imply a fresh string allocation every iteration?

 

At least there is an answer in there about memory allocation for the while loop vs. the for loop.  Not much difference for the 2M character test it seems.

 

Darin's LUT solution is pretty extraordinary, but again, if the task involves small strings and infrequent invocations, I'd rather avoid the explanation of how it works to a LV newbie...

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 27 of 29
(1,373 Views)

Chris and Dave,

 

I am still a novice and learning from you all..

 

Dave, I had a good laugh after seeing your reply.

 

There are few take away for me from this thread.

 

Thank you,

Vijay.

0 Kudos
Message 28 of 29
(1,346 Views)

@DavidBoyd wrote:

I know this post has been marked answered, but I just can't help myself.  And I do have the greatest respect for Chris' experience.

 

Mostly in answer to Vijay's several attempts (some flat-out wrong, and the final one close but improvable), I'll attach the following two images (note, only one is a snippet):

 

Efficient conversion of string of char pairs to U8 array.pngtire_swing.jpg

 

 

 

 

 

 

Apologies to all and best regards,

Dave


Gosh this picture brought me a lot of memory back (highschool...)... and still so true (especially now and in regards to my work..)

 

I'm glad to know that there is some sort of discussions about the efficiency (I already read those deadly talks about performances) even if formely I was more focused about the neat aspect of the thing.

 

 

Thanks to all of you 

 

0 Kudos
Message 29 of 29
(1,327 Views)