方法名稱長度是否對性能有任何影響？

Question

我是高級開發人員，所以這對我來說是一個愚蠢的問題。 我的回答應該是NO，或者是什么？ 沒有！！！

但我昨天正在開會，我正在解釋一些PMD結果。 當我們得到“太長的方法名稱”問題時，我開始解釋並且客戶說：好吧，並記住一個長方法名稱對性能有影響，程序運行速度較慢。

我說：不，你錯了，只是一個干凈的代碼規則，並且獲得一個好的代碼很重要，但與性能無關，字節碼與不同的名稱相似。

但客戶，會議中有一些人在此爭論，對此肯定。 他們有一些項目，因為長的方法名稱是導致性能不佳的原因。

我唯一的想法是，一些內省或反思的事情與此有關，但除此之外，我確信，或者我認為我當然，方法名稱長度沒有任何性能影響。

對此有何想法或建議？

Answer 1

可以說它會在內存和存儲空間中占用更多空間 - 因此，包含具有巨大方法名稱的類的jar文件將大於具有短類名的類。

然而，在性能上有什么區別是令人難以置信不太明顯。 我認為幾乎可以肯定的是，他們因為表現不佳而將長方法名稱歸咎的項目實際上被誤診了。 這不是第一次發生這種情況。

當然，從這種情況中獲取熱量的最佳方法是提供證據 - 如果性能很重要，您應該對性能進行測試。 使用長方法名稱運行這些測試，然后將它們重構為簡短的方法名稱並重新運行測試。 如果存在顯着差異，我會感到非常驚訝。

Answer 2

方法名稱不僅與反射相關，而且在類加載期間也是如此，當然在這兩種情況下，長方法名稱意味着在某種程度上CPU需要做更多。 然而，由於方法名稱長度甚至是遠程實用的（即長度不是數千個字符），我絕對肯定，與在反射或類加載期間必須完成的其他事情相比，這是不可能的。

Answer 3

但客戶，會議中有一些人在此爭論，對此肯定。 他們有一些項目，因為長的方法名稱是導致性能不佳的原因。

這聽起來像是一個被視為事實的總猜測。 這只是一些人對表現的一般性的一般情況。 即使它們恰好是正確的 ，也是完全可以猜測的。

每個程序都可以通過更改某些內容來提高性能。 猜測不會告訴你這些東西是什么。

如果兩個執行相同操作的程序具有不同的性能，則僅表示它們已經被不同程度地優化。 你的挑戰是解釋這一點。

Answer 4

如果縮短類名和成員名，則啟動時間將受到積極影響。 為此，可以使用字節碼收縮器 。

例如， yguard （LGPL）可以縮小代碼。 它還允許您對堆棧跟蹤進行反混淆處理以進行調試。

出於性能原因手動分配短類和成員名稱當然是一個可怕的想法。

Answer 5

我認為函數名稱的長度會對性能產生影響，如下所示：

1. 編譯從字節碼到二進制代碼的時間（使用java，.net，..）。 字節代碼仍包含文件名，類名，包名。
2. 如果我們使用* .lib，* .dll，* .so它可能會影響性能（在android中，例如當你使用本機代碼時）
3. 當我們使用本機代碼調用java函數時（在java，android中）

當黑盒子（lib文件，app）連接到其他黑盒子（lib文件，app）時，它使用頭文件中的函數名作為異化。 所以我認為名稱的長度會影響性能。

Answer 6

使用Asp.Net CORE 2 WebAPI時，ResponseObject內的任何Property的長度 - > DOES HAVE AN IMPACT < - 響應時間

這已經在處理簡單GET請求的ASP.NET Core 2 Web API上進行了測試。

首先我做了一個這樣的ResponseObject：

public class CelestialObjectResponse
{
    public CelestialObject CelestialObject { get; set; }
    public CelestialObjectClassification CelestialObjectClassification { get; set; }
    public CelestialObjectMeta CelestialObjectMeta { get; set; }
    public CelestialObjectPosition CelestialObjectPosition { get; set; }
    public IQueryable<CelestialObjectMarket> CelestialObjectMarkets { get; set; }
    public IQueryable<CelestialObjectResponse> Children { get; set; }
}

當我打電話給我的API來獲取大約1000個天體條目（每個都有分類，元，位置，市場等......）的數據時，這導致了6.8Mb的請求。

一旦我重構了ResponseObject，就會有更短的屬性名稱，如下所示：

public class CelestialObjectResponse
{
    public CelestialObject CO { get; set; }
    public CelestialObjectClassification COCL { get; set; }
    public CelestialObjectMeta COME { get; set; }
    public CelestialObjectPosition COPO { get; set; }
    public IQueryable<CelestialObjectMarket> COMA { get; set; }
    public IQueryable<CelestialObjectResponse> Children { get; set; }
}

那么ResponseObject的大小產生了一個6.2Mb的包，它比上一個響應速度快〜300ms ...

所以關於這一點，我可以得出結論，如果你使用Asp.Net Core Web Api，那么響應屬性的長度對Asp.net API中響應的加載時間有影響。 請注意，我可以在CelestialObject，Classification，Meta，Position，Market Classes中重構更多屬性，以使響應大小更小！

所以基本上這是一個很好的事情，但不幸的是我不知道運行時如何使用非常長的名稱來處理變量。 我可以想象在運行時有一些不明顯的小影響，但這很難說明。 除非您同時執行多個昂貴的操作，否則事情會加在一起並消耗很多性能，因此如果您覺得代碼中存在任何性能缺失，最好是診斷並檢查算法。

我希望這些小信息有所幫助

親切的問候

Answer 7

我不知道為什么它可能會顯着影響性能，除非你通過反射拉出方法名稱然后在UI上呈現它們。 顯然情況並非如此。 所以我只是感到困惑。 您確定您的客戶端不會將方法名稱與文件名混淆，或者他是否在考慮一些非常古老的編程語言不支持超長方法名稱的情況？ 根據這個人的年齡，他們的判斷對於計算機科學家來說絕對是荒謬的。 如果他們能夠證明自己的觀點，他們也可以將其提交給ACM，Oracle / Sun或麻省理工學院來驗證他們的發現。