不能足夠快地分配內存？

Question

假設您的任務是解決應用程序中的性能瓶頸問題。 通過分析，我們發現瓶頸與內存分配有關。 我們發現，無論我們分配多少內存線程，應用程序每秒只能執行N個內存分配。 為什么我們會看到這種行為，以及我們如何提高應用程序分配內存的速率。 （假設我們無法更改正在分配的內存塊的大小。假設我們無法減少動態分配內存的使用。）

Answer 1

好的，存在一些解決方案 - 但是幾乎所有解決方案似乎都是通過某種約束或其他約束來排除的。

1.有更多線程分配內存

我們發現，無論我們分配多少內存線程，應用程序每秒只能執行N個內存分配。

從這里，我們可以交叉任何添加更多線程的想法（因為“無論有多少線程”......）。

2.一次分配更多內存

假設我們無法更改正在分配的內存塊的大小。

顯然，我們必須分配相同的塊大小。

3.使用（某些）靜態內存

假設我們不能減少動態分配內存的使用。

這個我覺得最有趣的一點。提醒我一個關於FORTRAN程序員的故事（在Fortran進行動態內存分配之前），他剛剛在堆棧上使用了一個巨大的靜態數組作為私有堆。 不幸的是，這種約束使我們無法使用這樣的技巧。但是，它確實可以解決（解決方案）的一個方面。

---

我的解決方案

在開始執行時（無論是計划的，或在每個線程的基礎上）做出幾個^{^}內存分配系統調用。 然后在程序中使用稍后的內存（以及現有的動態內存分配）。

_{* 注意： '幾個'可能是一個確切的數字， 由您的分析確定，問題在開頭提到 。}

TL; DR

關鍵是要修改的存儲器分配的定時 。

Answer 2

...無論我們分配多少內存線程，應用程序每秒只能執行N次內存分配。 為什么我們會看到這種行為，以及我們如何提高應用程序分配內存的速率。

恕我直言，最可能的原因是分配來自一個共同的系統池。

因為它們共享一個池，所以每個線程都必須通過一些關鍵的段阻塞機制（可能是一個信號量）來訪問它。

競爭動態內存的線程越多（即使用new）將導致更多關鍵的段阻塞。

任務之間的上下文切換是浪費時間。

---

如何提高利率？

選項1 - 序列化使用...當然，這意味着您不能簡單地嘗試在另一個級別使用信號量。 對於我工作的一個系統，在系統啟動期間發生了高動態內存利用率。 在這種情況下，最簡單的方法是更改​​啟動，使線程n + 1（此集合）僅在線程n完成初始化並進入等待輸入循環后才開始。 只有一個線程一次啟動它，（並且很少有其他動態內存用戶在運行）沒有發生關鍵部分阻塞。 4個同步啟動需要30秒。 4個序列化的啟動在5秒內完成。

選項2 - 為每個特定線程提供ram池和私有new / delete。 如果一次只有一個線程訪問池，則不需要臨界區或信號量。 在嵌入式系統中，這里的挑戰是為線程分配合理數量的私有池而不是浪費太多。 在具有數GB的ram的桌面上，這可能不是一個問題。

Answer 3

看起來像一個具有挑戰性的問題，雖然沒有細節，但你只能做一些猜測。 （這很可能是這個問題的想法）

這里的限制是分配數量，而不是分配的大小。 如果我們可以假設您可以控制分配的位置，則可以一次為多個實例分配內存。 請將以下代碼視為偽代碼，因為它僅用於說明目的。

const static size_t NR_COMBINED_ALLOCATIONS = 16;
auto memoryBuffer = malloc(size_of(MyClass)*NR_COMBINED_ALLOCATIONS);
size_t nextIndex = 0;
// Some looping code
    auto myNewClass = new(memoryBuffer[nextIndex++]) MyClass;
    // Some code
    myNewClass->~MyClass();
free(memoryBuffer);

盡管你最有可能解決這個瓶頸問題，但你的代碼很可能變得更加復雜。 如果你必須返回這個新類，你甚至需要更多的代碼來進行內存管理。

根據這些信息，您可以為STL編寫自己的分配器實現，覆蓋'new'和'delete'運算符......

如果這還不夠，請嘗試挑戰限制。 為什么你只能進行固定數量的分配，這是因為獨特的鎖定？ 如果是這樣，我們可以改善嗎？ 為什么需要那么多的分配，改變正在使用的算法來解決這個問題......

Answer 4

我相信你可以使用一個可以負責內存分配的獨立線程。 該線程將具有包含線程標識符映射和所需內存分配的隊列。 線程不會直接分配內存，而是向隊列發送分配請求並進入等待狀態。 該隊列將嘗試從隊列中處理每個請求的內存分配並喚醒相應的休眠線程。 當負責內存處理的線程由於限制而無法處理分配時，它應該等到可以再次分配內存。

可以在解決方案中構建另一層，因為@ Tersosauros的解決方案建議稍微優化速度，但它應該基於類似於上述想法的東西。