2016-02-18 73 views
4

考慮:在這種簡單的情況下,我應該堅持使用LINQ嗎?

  float[] xPos = new float[pt3f.Count]; 
      float[] yPos = new float[pt3f.Count]; 
      float[] zPos = new float[pt3f.Count]; 
      for (int i = 0; i < pt3f.Count; i++) 
      { 
       xPos[i] = pt3f[i].X; 
       yPos[i] = pt3f[i].Y; 
       zPos[i] = pt3f[i].Z; 
      } 

我知道我可以在這裏使用LINQ

   var xPos = pt3f.Select(I => I.X).ToArray(); 
       var yPos = pt3f.Select(I => I.Y).ToArray(); 
       var zPos = pt3f.Select(I => I.Z).ToArray(); 

所以我的問題是除了一個更清潔的代碼使用LINQ,有沒有性能優勢?

我認爲就性能而言,使用單個for循環更快,我是對的,即3個Linqs最終將轉換爲3個循環。

+2

不,相反你在這種情況下表現不好。最後不是一個大問題,但你應該測量。 – Steve

回答

3

是的,LINQ示例將導致三個循環,而不是第一個示例中的循環。但在大多數實際情況中,您不會注意到任何差異,至少不會在小數組上。

除非你真的注意到性能問題,否則我個人更喜歡更易讀的LINQ版本。

+4

如果只有一個循環,linq的大多數版本也會變慢,因爲'Select()'已經丟失了信息來創建正確大小的數組,並且必須增量增長,然後在最後修剪。 (.NET Core對這種情況進行了優化,並且將以正確大小的數組開始,儘管它與其他方法相比仍有一些額外開銷)。這就是爲什麼如果性能是關鍵的linq方法*可能太慢的另一個原因,但正如你所說,最好保持更好的可讀性,直到它被證明是不夠的。 –

+0

@JonHanna非常有趣的部分關於優化...我不信任你,所以我去檢查它:-)(並且我看到你正在處理那部分代碼: - )...所以我是直接從馬的口中獲取信息:-)) – xanatos

+0

@xanatos在我甚至知道.NET Core已經打開之前,這個特殊情況已經被優化了,https://github.com/dotnet/corefx/commit/872bb70953bcfe0a47dcc6e9789fbd330e295bc3所以當我自從我進一步調整了這些路徑之後,我不太相信這匹馬:) –

相關問題