Convert Hexadecimal String to Byte Array

[altenbach]

---

@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. 😄

[DavidBoyd]

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

Dave

[altenbach]

---

@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

---

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

[altenbach]

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).

[Darin.K]

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

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

[altenbach]

---

@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) 😄

[DavidBoyd]

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

[Vijay_J]

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.

[Nelval]

---

@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):

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