Re: How turn-off C-run time library memory diagnostics?
Re: How turn-off C-run time library memory diagnostics?
- Subject: Re: How turn-off C-run time library memory diagnostics?
- From: John Stiles <email@hidden>
- Date: Fri, 05 Aug 2005 11:35:16 -0700
Gen Kiyooka wrote:
On Aug 5, 2005, at 8:33 AM, Erik Buck wrote:
malloc() and free() do not have particularly "fast" performance on
any non-real-time Unix variant. If you think malloc() and free()
are hard to use in high performance code, try automatic garbage
collection sometime :(
The solution that real-time software developers have used for the
last 25 years at least is to not dynamically allocate memory.
Standard alternatives include a one time large malloc() or vmalloc ()
or mmap() in the beginning and using/reusing that buffer over and
over. Free or munmap() the buffer outside "fast" code or just
before application exit or never.
I assume you are using Cocoa. There is an example in "Cocoa
Programming" that reuses the same memory buffer for multiple
instances of NSString. You don't even have to buy the book
(although an inexpensive digital version is available). You can
just download the examples from www.cocoaprogramming.net. If you
have the book, see Section "Avoiding Dynamic Memory Allocation" in
Appendix B "Optimizing and Finding Memory Leaks."
Actually, with a custom implementation of malloc/free, partitioning
allocations into pools of fixed size
blocks each of which uses a stack model to keep track of the free
list, the performance is quite good.
CodeWarrior MSL (RIP for Mac) has it's own malloc/free which do
something like this - calling into the
OS for larger chunks and issuing malloc/free new/delete calls from
the pool.
System-provided malloc/free can't be expected to be high-performers,
because they don't know anything about
your application's algorithm or memory usage patterns.
I've actually been really impressed by Apple's malloc and free.
Have you drag-raced it against a custom allocator (with real-world
allocation patterns) and seen it lose decisively? Which allocator beats it?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden