2016-07-16 19 views
1

鑑於這一功能:將不同號碼類型作爲參數發送到方法時是否存在性能問題?

void function(Double X, Double y, Double Z); 

是否有性能問題,如果我發送不同數量的數據類型?例如:

function(1, 2, 3); //int, int, int 
function(1, 2.2, 1); //int, double, int 
function(1.3f, 3.4, 2.34f) //single, double, single 
function(1.2f, 1, 1) //single, int, int 

.NET JIT如何管理它?它做拳擊拆箱?這會影響性能?

+1

我們在談論實際的文字或變量嗎?如果它們是文字,C#編譯器正在執行隱式轉換,並且沒有運行時成本。否則,運行時轉換的成本很低,但沒有分配(裝箱/拆箱)。 –

+1

這是一個在編譯時已知的常量類型。任何編寫玩具編譯器的本科生都可以在編譯器中完成。我認爲.NET編譯器人員可能可以管理。也就是說,假設你的例子中的代碼是你問的代碼。 –

+1

如果參數轉換時間與方法執行所需的總時間相比顯着,那麼如果在緊密循環中調用此方法,則性能成本只是一個問題。 – MickyD

回答

4

您的確切示例將由編譯器轉換,因此不存在性能損失。如果我們修改一下示例:

static void Test(double x, double y, double z) 
{ 
    Console.WriteLine(x * y * z); 
} 

static void Main() 
{ 
    double d1 = 1; 
    double d2 = 2; 
    double d3 = 3; 
    float f1 = 1; 
    float f2 = 2; 
    float f3 = 3; 
    int i1 = 1; 
    int i2 = 2; 
    int i3 = 3; 

    Test(i1, i2, i3); 
    Test(i1, d2, i3); 
    Test(f1, d2, f3); 
    Test(f1, i2, i3); 
} 

然後故事就不同了。該compilier將不大可能做轉換我們,所以它發出的代碼轉換,例如,讓我們來看看第二次調用的代碼Test

IL_004b: ldloc.s V_6 // Load the variable i1 onto the stack 
IL_004d: conv.r8   // Convert it to a double 
IL_004e: ldloc.1   // Load the variable d2 onto the stack 
IL_004f: ldloc.s V_8 // Load the variable i3 onto the stack 
IL_0051: conv.r8   // Convert it to a double 
// And call the function: 
IL_0052: call  void Example.ExampleClass::Test(float64, 
                float64, 
                float64) 

你可以看到它的必要它必須爲兩個非雙打再發出一條指令。這不是一個自由行動,需要時間來計算。所有這些說,我很難想象這個問題,除非你在一個非常緊密的循環中調用這個函數。

編輯

另外,請留意屬性訪問。例如,如果演示對象在for循環中沒有更改長度,則這兩個方法在邏輯上是相同的,但第一個方法會多次調用demo.Length,這肯定比調用一次要慢。

var demo = CreateDemo(); 
for (int i = 0; i < demo.Length; ++i) 
{ 
    // ... 
} 

// .. vs .. 

var demo = CreateDemo(); 
int len = demo.Length; 
for (int i = 0; i < len; ++i) 
{ 
    // ... 
} 
+0

IL解釋非常豐富。是的,我試圖用OpenGL中的遊戲循環來做到這一點,但我注意到我的變量並不總是相同的類型。有些是浮動的,有些是雙倍的,int。這就是我問的原因。我用兩種方式在兩種不同的計算機上測試了我的程序,一種是現代(2013)和一種非常老式(2001)。當我使用第一個解決方案時,老版本使用上千個GL線非常快速地進行了非常快速的處理,然後在執行我所問的內容時注意到了很多性能提升。我想我會嘗試在單一數據類型中進行調整,以查看它對性能的影響。 –

+1

夠公平的,確實存在這種情況。請記住要注意其他潛在的性能問題,比如很多不必要的函數調用(如果你有助手函數,例如,由於一個微不足道的活動,那麼你會付出一定的代價來將值推入堆棧,然後跳轉到函數在執行相同的內聯行爲時會更快)。此外,諸如數組訪問或屬性訪問之類的函數調用在某些情況下可以避免。 –

+0

哦!訪問屬性對性能有何影響O.O? 其實我正在訪問很多屬性jajaja也許這可能是一些東西...... –

相關問題