discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[2]: question about GNUstep memmory consumption


From: richard
Subject: Re: Re[2]: question about GNUstep memmory consumption
Date: Fri, 3 Nov 2000 11:10:36 +0000

On Thursday, November 2, 2000, at 10:28 PM, address@hidden wrote:

> On Thu, 02 Nov 2000 19:27:18 +0100 Helge wrote: 
>  >| I'm not sure how gstep-base maintains extra-retain-counts, but they 
>  >| might also add overhead (eg if stored in an external hashtable) here. 
>  
> Most code concerning this is located in NSObject.m. 
> ExtraRefCount seems to be located at obj[-1] (i.e. at object address - size 
> of int*). So 
> extra data are allocated for any object. It may depends on garbage collection 
> options,... 

GNUstep lets you build in a variety of different ways by setting preprocessor 
defines in NSObject.m
By default, it is configured to trade off memory efficiency for speed.

It stores both a 4-byte reference counter, and a 4-byte zone pointer before the 
object, so you have
(at least) an extra 8 bytes beyond the count for the data in the object 
itsself.  Also, allow for
the fact that the underlying malloc code might round up to (say) an eight byte 
boundary.

Next, in your loop all the objects created are going into an autorelease pool - 
which will need
a 4-byte pointer for each object released.
This makes the minimum memory usage for each object 8 (object data) + 8 (object 
overhead) + 4
(autorelease overhead) ... 20 bytes.

However, when an autorelease pool grows, it allocates a new chunk of memory 
twice as big as the
old filled one (perhaps a different algorithm might be better), so it's 
possible for you
(in the worst case) to have allocated 12 bytes of memory per object (plus some 
relatively
small overheads) in the pool.

Even this would only bring the memory usage up to 28 bytes per number - I can't 
really see how it
should be getting up to 84 bytes - perhaps the underlying malloc implementation 
is not working
efficiently for small blocks of memory.

Unfortunately I don't have time to step trhough everyting under gdb and find 
out what's happening.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]