內存與性能

Question

編程時一直在我腦海中，所以我想在它真正到達我之前吐出它。

我應該更擔心些什麼？應用程序消耗的內存或性能。我的意思是我應該專注於爲應用程序使用更少的內存，並使用更多的性能（例如，通過數據庫加載並在使用後轉儲它），或者使用更少的性能和更多的內存（例如緩存）

我的應用程序的條件： - 這是一個服務器應用程序，所以它並不意味着在臺式機上運行等，我有6GB的內存，我有一個四核。

Answer 1

你的問題引起了很多禪宗般的迴應。我希望做得更好。

你的內存限制很難：如果你超過了它，即使有虛擬內存，你的應用程序也會爬行，你將成爲所有人的笑柄。

您的CPU時間是無限的：您的應用程序將花費任何它需要的時間;希望它足夠平行，所有4個CPU將在大部分時間內全速烹飪，直到您的應用完成。

許多計算機科學問題都有各種各樣的解決方案，其中存儲器隨時間而變化。所以：在你至少使用大約一半的內存之前要記住大量的內存（如果這樣做有幫助的話，不要浪費它的內存！）但是當有足夠的內存時，請停下來，以免不必擔心超過即使在特殊情況下或意外情況下也是如此。

既然您已經分配了內存資源，那麼您可以嘗試調整代碼中的一些更小的性能收益。但不要麻煩過度。

完成。

P.S.如果它不能正確和可靠地工作，所有前面的努力都是毫無價值的。始終記住這一點！

祝你好運。

Answer 2

沒有一個正確的選擇 - 它取決於您的應用程序和它的要求。然而，這往往是一種選擇 - 你無法經常（如果有的話）最大化性能並減少內存消耗。如果這是任何一種關鍵系統，那麼對於內存和/或性能的最低界限應該由客戶指定 - 如果不是，他們應該是。

Answer 3

1. 讓它工作。

你會得到不同的答案，它誠實地依賴於每個應用程序。沒有覆蓋所有情況的覆蓋答案，除了：

1. 讓它工作。

軟件可能會被推翻。

具體而言，大多數操作系統在緩存磁盤I/O方面都非常出色 - 如果您正在使用SQLite數據庫進行大量繁重的工作，那麼當您在無論如何，操作系統很可能會把整個事情都拋在腦後。在大多數情況下，不要超出操作系統。

Answer 4

這取決於很多因素。哪兩個先限制？其他應用程序是否需要在同一臺服務器上運行？哪個更難延續？

Answer 5

考慮您將要處理的數據量和您需要的響應性。對設計進行一些思考。建立它是可維護的，並讓它工作。

然後配置文件，並解決您的實際瓶頸。

Answer 6

這取決於

提問有形的問題！

編輯：如果你想緩存在設計階段，然後回去開始和再次啓動它（緩存總是一個折衷的解決方案）！

Answer 7

即使您給出的規格仍然取決於應用程序將要看到的工作負載。

• 如果您一次只處理少量數據，則可能會通過預取下一個N塊來優化性能，從而增加內存消耗。
• 如果您的數據相當大，它可能很快就會完全填滿您的主內存，並且提前讀取會導致抖動（例如，在完成處理之前先強制將數據寫回磁盤/數據庫;然後您需要此數據回到內存中並由此強制交換這些預讀值）。

因此，首先得到您的應用程序的工作版本。然後進行分析並查看瓶頸是什麼。 （過早優化是萬惡之源！ - Donald E. Knuth）

Answer 8

它們都很重要。您可能想要緩存內存中的某些對象，以獲得更好的性能，這可能會增加內存佔用量。另一方面，如果您的應用程序花費了大量時間進行垃圾回收（如.net），或者擁有尚未釋放內存的非託管資源，您將遇到性能問題

Answer 9

我認爲您應該努力實現內存和處理器使用之間的平衡。

如果您正在使用服務器組件，我會擔心使其與多個用戶協同工作。你的應用程序可以提供多少用戶？你能否帶更多的用戶使用相同的資源？

Answer 10

您可以根據吞吐量和響應時間來考慮性能。找到衡量這兩個因素的方法，並設置系統需要處理和運行的負載類型。一旦你測量了負載下的吞吐量/響應時間，內存/處理時間（你稱之爲「性能」）的決定就來了。一般來說，您應該儘可能多地使用CPU（以獲得最佳吞吐量），以便利用所有可用的內存。

Answer 11

這個問題和編程本身一樣古老。不幸的是，答案是「這取決於」。如果您正在爲具有32 GB RAM的系統編寫應用程序，並且您的軟件是唯一將要運行的軟件，則應編寫代碼以充分利用該軟件。另一方面，如果您正在編寫將在嵌入式系統上運行的代碼，則應儘可能使用盡可能少的內存。最重要的是你知道這些權衡，分析你的代碼，並優化最大的瓶頸。

Answer 12

這真的取決於程序的種類。如果你可以控制目標機器，它會使它更容易一些。如果你知道即使在極端情況下，你也不會耗盡內存，那麼你也可以使用所有你想要的東西。內存沒有任何優勢。

在一般情況下，我想幾個類別的東西。

補充程序，如果程序沒有執行機器的主要用途，那麼它應該嘗試和節省內存，雖然不是服務器的東西，我通常認爲在這種情況下的例子是桌面小部件和Tomboy ..他們是不是主要用途，所以它們不應該從系統中佔用太多資源，這可能會潛在地損害主應用程序的性能。

一般應用，這些都有簡單的優先級。首先做好所需的工作，然後如果速度緩慢，就要加快速度。你不需要擔心內存太多，除非你是傻子（或使用python或java :-)）

許多實例應用程序。如果您希望用戶有多個應用程序實例，可以將其作爲多個任務或同一任務中的多個實例（如多個Firefox窗口/選項卡），因爲事情會增加，所以您需要對內存使用情況進行控制。速度不是一個讓操作更快以確保空閒實例實際上沒有進行任何處理的問題。

巨型應用程序，如果你的應用程序實際上有一個巨大的任務來執行，比如說圖像處理，那麼你應該從一開始就考慮內存使用。我懷疑Evolution會消耗很多內存（目前在我的機器上爲142 meg），因爲他們有巨大的任務但沒有意識到它。我有很多電子郵件，主要來自列表，

如果你可以控制你的目標環境，那麼你可以根據需要擁有儘可能多的內存，這對你更容易。如果其他用戶有你的程序，那麼需要更多的內存對你來說更容易，但對用戶來說並不友善。

我正在開發一個OLPC XO，很大程度上是爲了使系統與補充程序很好。這意味着我真的專注於低內存使用情況，但即使在限制內存的系統上，我也發現在進一步減少內存使用方面沒有多大用處。開機後，它有超過150兆免費。這足以運行你想要的所有輕量級應用程序，但大多數較重的應用程序將是一個壓力。中間地帶很少。進一步優化一個2兆應用程序只使用一個兆，如果你正在運行一個像Firefox這樣的應用程序，並不會給你更多的肘部空間。

Answer 13

你的客戶需要什麼？

你至少應該知道你的用戶將在哪個平臺上運行它。您還需要了解性能要求（每秒交易次數等）。對您需要的最低規格平臺進行一些保守估計，然後進行設計。

在您的文章中，您似乎也有點困惑 - 如果目的是將其用於緩存（即實際使用保存的內存以提高性能），則使用較少的內存不是最終目標。在這種情況下，無論什麼時候給你最大的開發時間。

Answer 14

最好不要從抽象的角度思考它，而應從具體的設計角度來考慮。

1. 如果您運行的RAM，你會後悔的，所以保持你的數據結構十分簡潔越好，即使它看起來你可能需要一些代碼迴路可能顯得效率低下。由於擔心性能，複雜的代碼和數據結構是過早優化的本質。而且，儘管人們反對過早優化並聲稱他們沒有這樣做，但他們無論如何也要做到這一點，甚至可怕的程度。

2. 當它工作並做你需要做的事時，如果你實際上有一個或多個性能問題，那麼處理性能。通常的方法是使用分析工具，但是this is the method I prefer。

小心多核。並行和線程允許您獲得多個時間重疊的代理，例如磁盤頭，CPU或人類客戶端。例如，如果您的進程受I/O限制，嘗試在多個內核上執行它們不會有太大幫助，並且可能會受到影響。如果只有一個物理磁盤驅動器，則嘗試重疊I/O綁定線程可能不會獲得太多收益，並且可能會受到影響。另一方面，如果你每個用戶都有一個線程，這可能是有道理的，因爲這些線程大部分時間都在等待用戶。