2010-06-11 44 views

回答

3

我不會關心100個函數。這是非常少的功能。

全局函數和方法被編譯,存儲在內存中,並在散列表中進行索引(保存用於最近實現的緩存查找)。因爲訪問哈希表的時間平均不變,所以在函數數量增長時調用函數時性能不會降低。

但是,會有更多的開銷解析腳本,並且如果實際調用所有這些函數,請編譯它們。如果你使用操作碼緩存,這不是一個真正的問題。還會有更多的內存開銷,但通常情況下,內存在企業級Web服務器中並不是問題,因爲儘可能快地嘗試提供請求,而不必關心內存。

也有風格問題。如果您的全局功能太多,請考慮是否:

  • 您正在複製這些函數之間的代碼。考慮重構,將通用代碼移至其他函數,並在適當的情況下通過添加參數來推廣函數的行爲。
  • 你會更好的分組功能,對類中的相同數據進行操作。

最後,只有在您對應用程序進行配置並查找函數調用成爲CPU瓶頸和函數定義成爲內存瓶頸時才擔心。

7

即使許多功能導致更多的內存消耗,我建議您仍然使用它們。一個明確的結構是比性能更重要。

性能可以提高throwing hardware at it,糟糕的結構應用程序變得很難維護。

順便說一句:100個功能是沒有!

+0

+1同意完全 – 2010-06-11 05:57:04

4

不,它不能。實際上,有很多功能是很好的,因爲這意味着你已經將代碼分成了更易管理的部分。一個很好的規則是保持你的功能小,讓他們只做一件事。哦,並且記得給你的函數命名,以便函數名稱很好地描述函數的功能。

有很多方法會在執行時產生一個小的開銷,但與從結構化代碼中獲得的好處相比,它是微不足道的,所以我不會擔心它。

6

100個函數不用擔心。如果你的代碼很慢,你應該將其配置爲明確地找到緩慢的部分。

請記住,過早優化是邪惡的

+0

'請記住,過早的優化是evil' MMH ..有點不以爲然;) 一個良好的規劃和設計本身就是總優化 – Strae 2010-06-11 06:28:22

+0

的一半@Daniel 試圖限制功能的數量,因爲一個猜測它可能是一個性能問題與完善的計劃完全不同。性能瓶頸並不總是顯而易見的,有時它在意想不到的地方。 – 2010-06-11 07:15:59

+0

「不成熟的優化是萬惡之源」 - Donald Knuth。 「遲來的悲觀是不好的葉子」 - Len Lattanzi。 – dalle 2010-06-11 09:14:01

2

只是讓你的代碼來做它的工作。不關心你的功能計數。

1

我認爲是一個項目可以有太多的功能。我不知道你如何設置你的項目,但它聽起來像你有功能庫。您可能會在將來考慮面向對象的開發。這使您可以將功能封裝到對象中。因此,該對象包含這些函數,並且它們對其他對象不可見(除非您希望它們是)。這有助於減少API污染。

對於你內存方面的擔憂 - 我也曾擔心過,請不要。良好的編程實踐對速度更重要。無論如何,你甚至都不會注意到Web服務器上的差異。永遠支持可維護性而不是速度!

相關問題