我有一個應用程序，最大限度地使用遞歸函數。基本上它是一個字符串解析器，它使用哈希映射作爲其數據結構。我們面臨的一個問題是，對於複雜而長的絃樂隊來說，表演受到嚴重打擊。我們不敢接觸哈希函數，因爲害怕迴歸。觀察到的是我們懷疑導致性能問題的大量遞歸函數調用。該應用程序是基於VS 2008開發的C++（Windows）堆棧保留大小和堆棧提交大小是否會增加提高應用程序性能？
增加堆棧保留大小和堆棧提交大小是否會提高應用程序性能？ OR 就會避免缺貨，我們遇到內存問題，但不經常
堆棧使用本身不會顯着影響性能。做函數調用的成本（恰好是遞歸調用）可能是散列函數運行時的重要部分，如果是這樣的話，迭代版本可能會更快。
最大在C++中使用遞歸可能效率低下，並且也有些危險，因爲堆棧大小有限。例如，
size_t hash(const std::string &s) {
if (s.size() == 0) return 0;
return s[0] + 31 * hash(s.substr(1));
}
這可能是原因（架空呼叫，並且它分配串負荷的可能性），效率低，而且還當過足夠長的字符串將用計算器崩潰。
我們不敢觸碰的散列函數，在迴歸
即使從性能拋開恐懼，在哈希表使用的哈希函數應進行隔離，便於維護的 - 一個副本的代碼，並且沒有任何其他地方假設使用任何特定的散列算法。
如果你可以隔離哈希函數，那麼你可以敢碰它。這樣，您可以輕鬆比較不同的哈希算法和不同的實現（包括遞歸/非遞歸），以查看它們是否解決您的整體性能問題。
如果你不能隔離哈希函數，那麼你已經學到了關於代碼設計的一課。不過，您仍然可以替換它，然後瞭解它是否會影響性能而不知道是否知道代碼仍然正確。如果你可以使它更快，那麼值得嘗試使其更正確（通過修改代碼的其餘部分來隔離哈希函數，然後替換它）。如果你能想到的最好的散列函數不會更快，那麼它是否正確無關緊要，因爲沒有理由使用它。
將增加堆棧保留大小和堆棧提交大小提高應用程序的性能？
幾乎可以確定它對性能沒有明顯的影響。
它會避免我們遇到的內存不足問題嗎？
不會。如果用完堆棧空間，則會出現堆棧溢出錯誤，而不是內存不足。
將遞歸代碼轉換爲迭代的幫助？ –
我不知道。我不知道你的程序在做什麼。我只是回答了你問的問題。但是如果你解決了內存問題，那麼你的問題不是你的堆棧太小。 –
幾乎可以肯定的是，從C++編譯器中獲得尾部調用優化很少見。通過查看反彙編很容易看出，如果在遞歸調用中您看到CALL而不是JMP，那麼您將通過迭代算法超前。 –
你是否對此進行了分析？ –
@James由於模塊是應用程序的核心，因此非常難以描述，如果我們嘗試剖析它，我們可能得不到正確的圖片 –