2014-05-11 95 views
0

我的印象是,列表(中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的任何提示?

+2

你不會想要列表始終具有完全相同的多種元素的能力。列表增長的方式是戰略性的。每次要添加元素時,都不必執行分配。在你的情況下,由於你存儲的元素數量龐大,它可能會大大擴展。如果你知道你需要一定的尺寸,然後將你的列表初始化爲該容量。當然,如果你需要一個靜態大小,你也可以使用一個數組...... –

+0

列表或數組可能需要兩倍的內存是沒有意義的。它是*虛擬內存*,只是處理器的一個編號。直到你訪問它,你纔開始使用*真實*內存。高端當然從未發生過。當你編寫消耗所有可用地址空間的程序時,你就會編寫錯誤的代碼。任何從dbase讀取jigabyte數據然後對其進行處理的程序都可以重寫爲一次處理一行,只需要千字節。你可以通過允許它在64位模式下運行來編寫不好的代碼,很難耗盡地址空間 –

+0

我不認爲它是虛擬的,我編譯爲64位,而當內存使用達到15GB左右時(我總共有16GB物理內存),因內存不足而異常。 PS!我真的不想在64位編譯它的原因是,這也使整個事情運行速度顯着緩慢(如我的措施30%) 我得到你說關於加載所有數據一炮而過,但隨機分佈式處理將成爲一片喧囂,每次去磁盤都會起反作用。 –

回答

0

我很想看看,如果你要在你的包裝只使用一個多頭排列,而不是一個列表(長)和動態調整其大小爲您添加新號碼的表現會如何比較。試試這個。將Long傳遞給構造函數以初始化包裝器的內部數組,然後使用Add方法添加更多數字。您可以從MyArray屬性中檢索當前數組。

Public Class FunnyList 

    Private _myArray As Long() 

    Public Sub New(n As Long) 
     _myArray = New Long() {n} 
    End Sub 

    Public Sub Add(n As Long) 
     Dim iUBound As Integer = _myArray.GetUpperBound(0) 
     ReDim Preserve _myArray(iUBound + 1) 
     _myArray(iUBound + 1) = n 
    End Sub 

    Public ReadOnly Property MyArray() As Long() 
     Get 
      Return _myArray 
     End Get 
    End Property 

End Class 
+0

好吧,我試了一下,調光比較慢(比數千倍慢)。我懷疑它使用了與我最初使用的Array.Resize類似的機制,並且速度太慢。它也使內存使用起來和下來,我認爲它只是創建一個新的陣列,並在每一次完全複製舊的。 –