[Mono-list] Unable to create more than 1000 objects.

Rodrigo Kumpera kumpera at gmail.com
Mon Dec 12 11:42:31 EST 2011


On Mon, Dec 12, 2011 at 7:46 AM, Simon Lindgren
<simon.n.lindgren at gmail.com>wrote:

> Your test program does not fit your description very well, only creating
> 10000 objects and that Unit being of ~4MB size instead of 100B.
>
> I could only test up to 4GB of memory since that is the limit of the
> mono in the Fedora 16 repos, but for me the run time seems to scale
> linearly with growing length of the Unit array. My adapted test code
> (with much smaller object size to exaggerate object construction):
>
> using System;
>
> class Test {
>  static Unit[] units = new Unit[50000000];
>   static public void Main () {
>     for (int i = 0; i < units.Length; i++) units[i] = new Unit();
>    Console.WriteLine("Now having " + units.Length + " units. " +
> (GC.GetTotalMemory(false) / 1000000).ToString() + " MB");
>  }
> }
>
> class Unit {
>  int[] dummy = new int[1];
> }
>
> time mono --gc=sgen memtest.exe
> Now having 50000000 units. 3612 MB
> mono --gc=sgen memtest.exe  11,98s user 0,93s system 179% cpu 7,214 total
>
> An observation:
> 3612000000 bytes / 50000000 objects = 72 bytes/object
> 72 bytes - 20 bytes = 52 bytes overhead in object instance storage.
>


Your numbers need some polishing.

First, an object has a 2 words header, so 16 bytes on 64bits systems.
Then array, they have 4 words header, so 32 bytes on 64bits systems.

Let's measure what the expected size would be:

class Unit: 24 bytes: 16 bytes header + 8 of the dummy field
new int[1]: 40 bytes: 32 for the header + 4 of the one element + 4 padding

 Unit[] array. Each slot takes 8 bytes.

Summing up: 24 + 40 + 8 = 72 bytes. Which is pretty much what you found
out experimentally.

Besides that, your 72 - 20
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20111212/0385c737/attachment.html 


More information about the Mono-list mailing list