我的印象是,列表(中T)是圍繞一個基本陣列但今天的實用程序包裝器測試時,我發現列表是高達兩倍的大小在存儲器中作爲陣列下。這與我有關,因爲在我目前使用列表實現的情況下,數據庫大約有1.5GB,這對於我的口味來說過於接近32位限制,因爲這不包括程序的其餘部分。如果我能將這一切削減一半,那就太棒了。列表和數組大小差異
我用列出了他們的conventient調整的能力,但我想我也許可以建立自己的包裝類各地陣列來實現同樣的事情在較低的內存使用情況。因此,我所做的測試是這樣的:
Public Class funnylist
Private arrlist As New List(Of Long())
Private rcount As Integer = 0
Private incsize As Integer = 1000
Private lastArr As Integer = -1
Private maxCount As Integer = 0
Private lastsub As Integer = -incsize
Public Sub add(n As Long)
If rcount = maxCount Then
arrlist.Add(New Long(incsize) {})
lastArr += 1
lastsub += incsize
maxCount += incsize
End If
arrlist(lastArr)(rcount - lastsub) = n
rcount += 1
End Sub
End Class
能明顯使用一些拋光但概念它的工作原理的證明,對於相同數量的項目的內存佔用一半(長)列表。問題是,我用1000萬個數字5填充了列表和funnylist,並對它進行了計時。列表的速度是這樣做的兩倍。所以我想知道在List的引擎下究竟發生了什麼?它爲什麼更大,爲什麼它更快?有關改進我的funnylist的任何提示?
你不會想要列表始終具有完全相同的多種元素的能力。列表增長的方式是戰略性的。每次要添加元素時,都不必執行分配。在你的情況下,由於你存儲的元素數量龐大,它可能會大大擴展。如果你知道你需要一定的尺寸,然後將你的列表初始化爲該容量。當然,如果你需要一個靜態大小,你也可以使用一個數組...... –
列表或數組可能需要兩倍的內存是沒有意義的。它是*虛擬內存*,只是處理器的一個編號。直到你訪問它,你纔開始使用*真實*內存。高端當然從未發生過。當你編寫消耗所有可用地址空間的程序時,你就會編寫錯誤的代碼。任何從dbase讀取jigabyte數據然後對其進行處理的程序都可以重寫爲一次處理一行,只需要千字節。你可以通過允許它在64位模式下運行來編寫不好的代碼,很難耗盡地址空間 –
我不認爲它是虛擬的,我編譯爲64位,而當內存使用達到15GB左右時(我總共有16GB物理內存),因內存不足而異常。 PS!我真的不想在64位編譯它的原因是,這也使整個事情運行速度顯着緩慢(如我的措施30%) 我得到你說關於加載所有數據一炮而過,但隨機分佈式處理將成爲一片喧囂,每次去磁盤都會起反作用。 –