2011-11-12 341 views
5

我正在分析一些C#代碼。下面的方法是最昂貴的方法之一。爲了這個問題的目的,假設微優化是正確的。有沒有一種方法來提高這種方法的性能?優化C#代碼片段

將輸入參數更改爲pulong[]會造成宏觀效率低下。

static ulong Fetch64(byte[] p, int ofs = 0) 
{ 
    unchecked 
    { 
     ulong result = p[0 + ofs] + 
      ((ulong) p[1 + ofs] << 8) + 
      ((ulong) p[2 + ofs] << 16) + 
      ((ulong) p[3 + ofs] << 24) + 
      ((ulong) p[4 + ofs] << 32) + 
      ((ulong) p[5 + ofs] << 40) + 
      ((ulong) p[6 + ofs] << 48) + 
      ((ulong) p[7 + ofs] << 56); 
     return result; 
    } 
} 
+3

看起來像BitConverter.ToInt64 - http://msdn.microsoft.com/en-us/library/system.bitconverter.toint64.aspx? –

+0

閱讀並移動幾個字節 - 是否真的很貴?我敢肯定,你打了很多電話,但是如果編譯器可能會在那個 – Rup

+1

@Alexei ToUInt64上出錯,但是是的,我會感到驚訝。如果您的意思是使用它,請將其作爲答案發布? (或者Eric想要甚至優化BitConverter?) – Rup

回答

5

爲什麼不使用BitConverter?我必須相信微軟花了一些時間來調整代碼。另外它處理endian問題。

這裏的BitConverter如何變成一個byte []爲長/ ULONG(ULONG將其轉換爲簽署,然後把它強制轉換爲unsigned):

[SecuritySafeCritical] 
public static unsafe long ToInt64(byte[] value, int startIndex) 
{ 
    if (value == null) 
    { 
    ThrowHelper.ThrowArgumentNullException(ExceptionArgument.value); 
    } 
    if (((ulong) startIndex) >= value.Length) 
    { 
    ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.startIndex, ExceptionResource.ArgumentOutOfRange_Index); 
    } 
    if (startIndex > (value.Length - 8)) 
    { 
    ThrowHelper.ThrowArgumentException(ExceptionResource.Arg_ArrayPlusOffTooSmall); 
    } 
    fixed (byte* numRef = &(value[startIndex])) 
    { 
    if ((startIndex % 8) == 0) 
    { 
     return *(((long*) numRef)); 
    } 
    if (IsLittleEndian) 
    { 
     int num = ((numRef[0] | (numRef[1] << 8)) | (numRef[2] << 0x10)) | (numRef[3] << 0x18); 
     int num2 = ((numRef[4] | (numRef[5] << 8)) | (numRef[6] << 0x10)) | (numRef[7] << 0x18); 
     return (((long) ((ulong) num)) | (num2 << 0x20)); 
    } 
    int num3 = (((numRef[0] << 0x18) | (numRef[1] << 0x10)) | (numRef[2] << 8)) | numRef[3]; 
    int num4 = (((numRef[4] << 0x18) | (numRef[5] << 0x10)) | (numRef[6] << 8)) | numRef[7]; 
    return (((long) ((ulong) num4)) | (num3 << 0x20)); 
    } 
} 

我懷疑這樣做轉換一個32位字的一個時間是32位效率。 32位CPU上沒有64位寄存器意味着處理64位整數的代價要昂貴得多。

如果您確定自己的目標是64位硬件,那麼一舉做轉換可能會更快。

+0

值得注意的是,這是使用不安全的代碼來提高性能;似乎BCL方法是最好的選擇。 –

+0

D'oh!在今天的不同背景下使用BitConverter並沒有想到這一點。順便說一下,這種優化將CityHash的C#端口的整體性能提高了30%(使其比現在移植的C++版本快28%)。 –

1

僅供參考,微軟的.NET 4.0 BitConverter.ToInt64(共享源代碼計劃在http://referencesource.microsoft.com/netframework.aspx):

// Converts an array of bytes into a long. 
    [System.Security.SecuritySafeCritical] // auto-generated 
    public static unsafe long ToInt64 (byte[] value, int startIndex) { 
     if(value == null) { 
      ThrowHelper.ThrowArgumentNullException(ExceptionArgument.value); 
     } 

     if ((uint) startIndex >= value.Length) { 
      ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.startIndex, ExceptionResource.ArgumentOutOfRange_Index); 
     } 

     if (startIndex > value.Length -8) { 
      ThrowHelper.ThrowArgumentException(ExceptionResource.Arg_ArrayPlusOffTooSmall); 
     } 

     fixed(byte * pbyte = &value[startIndex]) { 
      if(startIndex % 8 == 0) { // data is aligned 
       return *((long *) pbyte); 
      } 
      else { 
       if(IsLittleEndian) { 
        int i1 = (*pbyte) | (*(pbyte + 1) << 8) | (*(pbyte + 2) << 16) | (*(pbyte + 3) << 24); 
        int i2 = (*(pbyte+4)) | (*(pbyte + 5) << 8) | (*(pbyte + 6) << 16) | (*(pbyte + 7) << 24); 
        return (uint)i1 | ((long)i2 << 32); 
       } 
       else { 
        int i1 = (*pbyte << 24) | (*(pbyte + 1) << 16) | (*(pbyte + 2) << 8) | (*(pbyte + 3)); 
        int i2 = (*(pbyte+4) << 24) | (*(pbyte + 5) << 16) | (*(pbyte + 6) << 8) | (*(pbyte + 7)); 
        return (uint)i2 | ((long)i1 << 32); 
       } 
      } 
     } 
    } 
1

爲什麼不去不安全?

unsafe static ulong Fetch64(byte[] p, int ofs = 0) 
{ 
    fixed (byte* bp = p) 
    { 
    return *((ulong*)(bp + ofs)); 
    } 
}