Re: memory. and a lot of continual small object allocations and deallocations.
Re: memory. and a lot of continual small object allocations and deallocations.
- Subject: Re: memory. and a lot of continual small object allocations and deallocations.
- From: Ben Dougall <email@hidden>
- Date: Sat, 19 Apr 2003 00:42:24 +0100
On Friday, April 18, 2003, at 09:07 AM, Ben Dougall wrote:
does cocoa's runtime deal with continual allocation and deallocation
of small amounts of memory from small objects reasonably? does it not
release memory immediately back to the system, incase the app needs
some new memory for something else the next second/minute? is there
anyway for your app to reserve a chunk/block of memory, so when it
allocates and deallocates it doesn't release the memory back to the
system but keeps it for later?
On Friday, April 18, 2003, at 03:48 pm, publiclook wrote:
You can always implement your own memory management and store caches
of objects for reuse etc. I think there is an example in "Cocoa
programming" called "short string" or something. Try downloading it.
You don't even have to buy the book.
yeah, in that example nsstring (a class cluster obviously) is
subclassed, which looks a bit of a minefield (undocumented inits for
example), but i guess, maybe, using categories you could override the
releases - that's what would be required right? use categories rather
than subclassing. re-implement the releases on whichever
classes/objects you wanted this to work with. not sure how feasible
that would be - with not being able to create instance variables, and
with not being able to see the existing implementation of the releases
- but maybe those two things wouldn't be a problem. - i'm not sure.
maybe adding a new type of release rather than overriding, leaving an
option between the two would be a better way.
However, Unix malloc and free (presumably what Cocoa is using) have
been around for a long time and are reliable and fast (compared to
other systems) for an amazing breadth of uses...
i have read that dynamic memory allocation and deallocation is a quite
an efficiency drain, and i foresee initiating and releasing a lot of
small objects, so i was just seeing a potential shortcut, to get some
reasonable savings without too much work, possibly.
However, having said all that, malloc and free are still system calls
and can in some circumstances take a lot of time.
that's the impression i've got, and if i know i'm going to want that
memory again very soon - seems silly to pass it backwards and forwards.
might aswell just keep it.
On Friday, April 18, 2003, at 04:15 pm, Timothy Ritchey wrote:
It depends on what you mean by "back to the system."
not owned / held by the app any more - back to the system
..When a request is made for a block of memory, first the free list is
checked to see if there is any available space, and only if there is
no room in the existing regions is a new region added. As blocks are
allocated and freed, the regions act as a pool of resources which can
be quickly accessed by malloc without needing to call the underlying
page allocation functions...... The zone does not immediately destroy
blocks when an process frees them. If a request for memory comes
along, this free-but-not-deleted list is first checked for a large
enough block to fulfill the request before requesting pages from the
operating system....
so when memory is deallocated it goes to a kind of intermediate stage
where it can be easily and quickly got back again, assuming that memory
in the entire system isn't particularly tight and therefore hasn't been
gobbled up by something else? but still putting it back into even this
intermediate part would be less efficient than just keeping it in the
first place though i'd have thought?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.