Possible Improvements with ByteArrayToHexViaLookup & ByteArrayToHexViaLookupPerByte

[GregDomjan]

I'd make a pull request to include some changes, but git is giving me grief.

Was originally looking at http://www.codeproject.com/Tips/447938/High-performance-Csharp-byte-array-to-hex-string-t

Adding it to the tests showed it had better performance than others, but of course has the problem of being 'Unsafe'.

Without changing the basic types in use and method there are some ways to improve ByteArrayToHexViaLookup.

1. Having the table created in the method each time it is called adds an unnecessary overhead.

2. There is a small performance hit to using ForEach when you only use the variable once inside the loop. (http://www.dotnetperls.com/for-foreach)

   static readonly string[] HexStringTable = Enumerable.Range(0, 255).Select(i => i.ToString("X2")).ToArray();
   
   static string ByteArrayToHexViaLookup(byte[] bytes)
   {
       var result = new StringBuilder(bytes.Length * 2);
       for (var i = 0; i < bytes.Length; i++) {
           result.Append(HexStringTable[bytes[i]]);
       }
       return result.ToString();
   }
   

The String builder is also slowing this down just a bit - changing how the string is prepared to using an array similar to ByteArrayToHexViaLookupPerByte

    static string ByteArrayToHexViaLookupArrayIndex(byte[] bytes)
    {
        var result = new char[bytes.Length * 2];
        for (var i = 0; i < bytes.Length; i++)
        {
            var val = HexStringTable[bytes[i]];
            result[2 * i] = val[0];
            result[2 * i + 1] = val[1];
        }
        return new string(result);
    }

Also tried Concat but it does worse than ByteArrayToHexViaLookupAndShift as content size increases

    public static string ByteArrayToHexViaLookupConcat(byte[] bytes)
    {
        var result = new string[bytes.Length];
        for (var i = 0; i < bytes.Length; i++)
        {
            result[i] = HexStringTable[bytes[i]];
        }
        return string.Concat(result);
    }

Trying to see if there was some way to merge the ByteArrayToHexViaLookupPerByte with ideas from the Unsafe method using more direct allocation rather than shifting. The following performs better for larger strings, but takes a hit from double memory alloc on small strings. I have not seen an alternate method for 'casting' an array type.

    static string ByteArrayToHexViaLookupPerByteAssignAndBlockCopy(byte[] bytes)
    {
        var temp = new int[bytes.Length]; 

        for (var i = 0; i < bytes.Length; i++)
        {
            temp[i] = (int)HexUintTable[bytes[i]];
        }
        var result = new char[bytes.Length<<1];
        Buffer.BlockCopy(temp, 0, result, 0, result.Length<<1);
        return new string(result);
    }

[patridge]

Thanks for all the feedback. I'll see if I can incorporate some of those ideas soon and re-run the output.

I started running into that per-call overhead on the last test addition. I was really fond of keeping everything encapsulated in a single method, but ended up using a static field for that one to avoid the per-call look-up creation. (I should probably figure out better encapsulation of test runs anyway.)

I definitely need to make similar accommodations for the other methods that need to create look-up data. I even had uncommitted code where I had moved the original pre-defined array out of that method, but I'll probably opt to use the simplified Enumerable.Range version instead for less clutter.

[airbreather]

#3 does as much as I could think of to amortize the overhead that would be amortized in practice.

@GregDomjan you could try declaring the local array as uint[]... but besides the double-allocation and the byte copying, I believe that another part of the reason the unsafe variant outperforms what you have there is the fact that the compiler doesn't implement the smarts to statically prove that "i" is always a valid index on "temp", so it emits a bounds check on every access through that loop. There's actually a really scary way to avoid the double allocation along these lines, but if we're going into unsafe territory anyway, we might as well just use the unsafe version of this posted by CodesInChaos anyway...

FWIW, I've heard that Microsoft's optimizer (so probably Mono's as well?) will translate a "foreach" loop over an array into an equivalent "for" loop in cases like ByteArrayToHexViaLookup, so you probably wouldn't see any runtime difference in changing that particular "foreach" into "for".