設計模式的效率

有沒有人知道任何有關圍繞高性能應用程序設計模式的最佳實踐或理論的網站/書籍/文章？看起來很多模式以可能影響計算密集型代碼的性能的方式使用間接/抽象/封裝。首先設計模式，甚至是GoF都會提到與許多模式相關的性能命中的可能性，但沒有關於如何處理它的更具體的建議。設計模式的效率

來源

2010-08-06 Maksim Kneller

我很驚訝，我們並不要求你有什麼性能問題，有一個關於高性能網絡的模式很多papers！

以我的經驗，性能問題通常是依賴於特定的條件和情況。另一方面，設計模式是解決更一般和抽象問題的方法。在同一篇文章中處理兩者似乎有些尷尬：作者應該比較設計模式的性能與可能的許多「非模式化」解決方案？當性能問題一般，當然已經有解決它們的模式：Flyweight就是一個很好的例子。

通過使用設計模式判處罰款是一種有限的，非常小的一組：引入虛擬來電，增加的等待時間，由於代表團，額外的內存消耗，因爲對象等的增殖。如果在分析後發現這些是造成你的災難的原因，那麼有一些已知的方法可以將它們降到最低。

知道的模式可能是解決性能問題很有用。首先，有人已經提到模式可以用較小的比特來分解問題：這可以簡化查明問題的根源並隔離醜陋但性能高的代碼。他們還爲開發人員創建了一個推理和期望框架。如果你必須引入出於性能方面的偏差，這將是顯而易見的：「除了這裏，在這裏我們放棄X，做y以提高性能，這是責任的鏈。」他們是規則，在需要的時候被打破。

（唉，對獲得良好性能的一個很好的模式：測量，精確定位，修復。）

來源

2010-08-06 02:03:55 andref

你的回答比我的更清楚，更清晰，同時說大致相同的事情。 – Omnifarious 2010-08-06 02:27:39

設計模式的重點在於如何構造代碼並定義類的抽象和交互。您的計算性能的性能將主要受您編寫實際代碼實現（方法主體）的方式影響。

對於C++，我絕對建議閱讀Scott Meyers關於Effective C++和更高效的C++系列書籍，這本書本身在編寫高性能代碼時真正揭示了許多成語。

來源

2010-08-06 01:15:11

嗯...他們是很好的書。但我認爲在性能問題上花費的時間並不多。在某些情況下，他們會向您展示「鑑於性能問題A，您可以使用C++慣用語B來解決這個問題」，但是根本沒有關於程序設計的速度問題。 – 2010-08-06 01:34:09

同意，不是直接，但更多的是讚賞內部核心/內存以及如何編寫乾淨有效的代碼。 Addison Wesley的高效C++可能更適合所問的問題。在過去的2年裏，我沒有寫出太多的C/C++，而最後一次閱讀這些書籍的時間很多年前，因此無法具體指出細節 – 2010-08-06 01:47:50

設計模式的存在幫助您掌握如何設計軟件或提高其靈活性。你如何實現這個模式決定了你從使用中會看到什麼樣的性能損失（或者好處）。

某些模式確實存在，因爲構建事物的整體方式通常會導致更快的程序。但與算法不同的是，沒有什麼好方法可以真正正式地分析模式，以決定它的速度有多慢。

我的建議是使用一個模式，如果它可以幫助你弄清楚如何設計一段特定的代碼，或者如果你需要重構代碼使其更加靈活或清晰。如果您遇到性能問題，請使用標準分析技術來查找它們。

如果您在遇到性能問題時進行重構，也許成本不值得重構，或者可能有一種方法來緩解它。如果你正在設計新的代碼，也許有辦法改變事情來解決性能問題，如果它確實存在於模式工作的必要間接中。

來源

2010-08-06 01:16:07 Omnifarious

最具體的建議是：在應用程序中對其進行配置並查看它實際產生的影響有多大。

任何其他的建議將會相當普遍，可能不一定適用於您如何在您的平臺上使用編譯器在您的應用程序中實現了給定模式。

來源

2010-08-06 01:25:00 TheUndeadFish

對於涉及多線程和併發模式以及它們如何影響性能的內容，您可以閱讀「有效併發」下的Herb Sutter條目。

http://herbsutter.com/

來源

2010-08-06 01:28:52 David

這與GoF樣式設計模式有什麼關係？ – 2010-08-06 01:33:31

OP談到高性能應用程序和我認爲的多線程和併發環。 – David 2010-08-06 01:42:41

我沒有詢問表現。當然，線程化是性能優化。我問到它與GoF樣式設計模式有什麼關係。 – 2010-08-06 02:05:37

設計模式大多是破壞你的程序成小塊，這更容易被重用，撰寫，設計和測試的方式。一些設計模式會導致代碼的執行比簡單的設計更差，但是當您考慮80/20規則時，它們具有顯着的優勢。

80/20規則說你的程序80％的執行時間將花在執行其代碼的20％上。當你的程序非常好並且模塊化時，很容易將它扔進一個探查器中，看看究竟哪個組件可以被調整/優化，或者在哪裏使用不太靈活的設計來提高性能。儘管最初分離的設計使得更容易找到性能熱點。

來源

2010-08-06 01:37:35

可能幫助您獲得更好點擊的一個術語是「模式語言」。它是爲了某種目的而聚集在一起的模式集合。如果您有一個更具體的目標，即高績效的某人可能已繪製出通過您的域的模式的路徑，例如：pattern language for parallel software。這是來自UIUC的另一個不錯的收集parallel programming patterns，這是模式工作的溫牀。

的ACE/TAO傢伙用C++

來源

2010-08-06 02:01:15

的GoF設計模式是關於使用經過驗證的模式來解決與優雅，易於維護的代碼的常見問題。他們不針對性能。

如果你想爲表演方式，你可能需要看看系統架構模式，算法，數據結構等

什麼是您的應用程序嗎？

如果你的應用是在C++，並明智地寫，機會是你的代碼將在現代化的硬件上運行瞬息萬變，直到它必須等待I/O。例外情況就像是處理器密集型的實時圖像分析。

如果性能是一個問題，你真的是I/O性能？（磁盤，數據庫，網絡等）

有「模式」，讓您的應用程序執行即使在頻繁等待I/O（異步回調等）

如果你正在處理一個負載不均，由此峯值負載可能比平均負載高得多，通常採用的架構模式是將系統組件與消息隊列分離。

來源

2010-08-06 02:10:04 saille

還記得那句老話：「你可以擁有它，快速和便宜，選擇兩個」
設計模式解決了這個問題。需要一個良好的基礎，以便代碼準確，可維護。
如果性能問題，然後基準，然後優化給你問題的部分。很多時候性能只是一個挑選適當算法的問題，但這可能意味着你需要分解爲一些可怕的優化代碼，這個10％的代碼佔用了90％的時間。只要確保你評論S ^^ T就可以了。

來源

2010-08-06 02:39:00

設計模式的效率

回答

相關問題