[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, mguesdon@oxymium.net 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.