2009-12-05 49 views
6

我可以像我想要的那樣使用偏色嗎?還是必須抑制自己以避免在很多流量下將我的視圖抓取到抓取位置?正在調用部分昂貴的操作?

+1

顯然有一些開銷,但我看到的一切都贊成用partials抽象。我期待着知道他們在做什麼的人回答這個問題。 +1是一個很好的問題。 – 2009-12-05 16:35:56

+0

通常,我會說「儘可能多地使用」。但這取決於渲染特定部分需要多長時間。如果尾部開發日誌('tail -f log/development.log')並加載頁面,您將看到渲染每個部分需要多長時間。如果一個或多個渲染速度緩慢,請找到加速或緩存的方法。否則,不用擔心。 – 2011-12-24 17:16:33

回答

11

有一個明顯的開銷部分,但這不是你應該擔心的。

部分是文件。當你渲染一個沒有偏見的動作時,你的動作「花費」1個文件(這不完全正確,但這是爲了簡化說明)。 如果您的行爲呈現4個部分,則最終的成本爲5.這意味着,您有4個額外的IO調用,每次調用的實際成本取決於您的服務器負載,服務器性能等。

但是,這樣做的代價很重要嗎?根據我的經驗,99%的時間沒有。同樣值得注意的是,在代碼可讀性和可維護性方面使用partials的好處通常是值得的選擇。

如果表演必須是關鍵功能,那麼您應該在其他地方尋找速度和改進。請記住:Ruby並不是一種超快速的編程語言,代碼表現力總是以表現爲代價的首位。 Rails隱含地同意這個慣例,儘管Rails團隊一直專注於性能(而Rails 3的實際演示總是有改進的地方)

也就是說,您可以安全地使用partials並減少一些聰明的應用程序開銷緩存機制。例如,您可以將集合渲染放置在cache區塊中,以便渲染集合語句只執行一次,然後您的應用程序將只加載1個緩存文件而不是10個未緩存的部分。

我一開始就犯了很多次錯誤之一,就是擔心錯誤的表現,沒有真正的運行基準。我記得有一次,當我試圖放棄一個單一的數據庫查詢而轉而使用硬編碼散列時,因爲「查詢花費」,卻沒有意識到還有另外一個愚蠢的查詢在沒有include語句的情況下加載整個表集合,導致運行第二個查詢慢3倍。因此,如果你真的關心性能,你可能不應該避免使用partials,而是確保你正在利用Rails提供的所有其他功能來擴展你的應用程序。

+1

這是答案 – 2009-12-05 21:50:00