2017-07-06 72 views
0

我有一個非常小的對象的巨大集合。爲了確保數據存儲非常緊湊,我重寫了類,以便將所有信息以可變字節編碼存儲在字節數組中。這些數百萬個對象的大多數實例只需要3到7個字節來存儲所有數據C中有效的小字節數組#

內存分析後,我發現這些字節數組總是至少需要32字節

有沒有一種方法可以將信息存儲得比字節[]更緊湊?指向非託管陣列會更好嗎?

class MyClass 
{ 
    byte[] compressed; 

    public MyClass(IEnumerable<int> data) 
    { 
     compressed = compress(data); 
    } 

    private byte[] compress(IEnumerable<int> data) 
    { 
     // ... 
    } 

    private IEnumerable<int> decompress(byte[] compressedData) 
    { 
     // ... 
    } 

    public IEnumerable<int> Data { get { return decompress(compressed); } } 
} 
+0

我添加了代碼。我必須存儲一些非常小的整數 - 因此可變字節編碼。 – user2033412

+0

這似乎是一個「問題」,與您在創建數組之前創建數組的方式有關。你能提供壓縮方法的源代碼嗎? –

+1

問題的一部分是對象開銷,在64位版本中更糟糕。這有一些關於這方面的信息:[內存和字符串](https://blogs.msmvps.com/jonskeet/2011/04/05/of-memory-and-strings/) – hatchet

回答

1

有你面臨着吃內存一對夫婦的問題。一個是對象開銷,另一個是對象對齊到32或64位邊界(取決於你的構建)。您目前的方法受到這兩個問題的困擾。以下資料描述得更詳細:

我這個玩,當我是fiddling with benchmarking sizes

一個簡單的解決方案就是簡單地創建一個具有長整型值的單個成員的結構。它的方法將使用移位和掩碼位擺弄來處理打包和解包字節的進出。

另一種想法是通過ID提供對象的類,並將實際字節存儲在單個後臺List<byte>中。但是這會變得複雜和混亂。我認爲結構想法更直接。

+0

我雖然很多關於一個大的支持數組和只存儲索引 - 但像你說的:這將是混亂。 – user2033412