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: publiclook <email@hidden>
- Date: Fri, 18 Apr 2003 10:48:42 -0400
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.
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. Generally speaking,
memory is always reserved in page size increments even if you ask for
something smaller. As long as there is room left in a previously
reserved page, new allocations come from there. Free usually just
marks memory as available for reuse. Pages that contain all or mostly
free space may be reclaimed by the operating system (coalescing blocks
of memory if necessary), but that only happens if another process wants
the memory. As long as more pages of physical memory are available, the
os typically does not do much work to implement free and your
application's R-size doesn't shrink even when free is called. As soon
as a combination of programs want more memory than is available,
disused pages are swapped out to disk and pages are recycled for
another application.
There is tons of literature on how dynamic memory management is
intelligently implemented, and I think you can see the source code for
Darwin if you care. However, having said all that, malloc and free are
still system calls and can in some circumstances take a lot of time.
Frequent allocation and deallocation of small objects does not tend to
fragment memory or cause other problems common on other platforms, but
for small objects, the time spent in system calls can easily dwarf the
time spent in the methods of the object itself. As a rule of thumb,
system calls cost at least in microsecond regardless of what system
call is made do to context switching etc. 1 microsecond is an eternity
to a modern processor even if it is imperceptible to users.
Cocoa does provide the NSZone features that aid with locality of
references. Use this feature to increase the chances that object which
are used together are physically close together in memory. Be very
careful though. Malloc is already very smart, and if you don't know
what you are doing, using NSZone might be worse than letting malloc
take care of everything.
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?
_______________________________________________
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.
_______________________________________________
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.