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: Timothy Ritchey <email@hidden>
- Date: Fri, 18 Apr 2003 23:18:16 -0500
It depends on what you mean by "back to the system."
not owned / held by the app any more - back to the system
Well, there are three levels really. The operating system kernel xnu,
Libc's malloc implementation, and your application. The pages are held
in the malloc implementation, but not returned to the kernel yet.
so when memory is deallocated it goes to a kind of intermediate stage
... ?
Pretty much. It is held by the default malloc zone, which happens to be
shared, but you can also create your own zone for your application. The
unused pages are still not strictly in your application, but they are
all together.
If you are actually finding object allocation/deallocation to be a
problem, then you might have a case for some kind of factory pooling
implementation. Allocation is only one half of the alloc/init cycle
though, so you are still going to take some kind of hit. Are all the
objects unique, or could you use a flyweight pattern? Anyway, I don't
have your original e-mail handy, so I don't remember if you mentioned
anything about the actual objects you want to create, so it is hard to
give any recommendations.
Just from the perspective of dealing with huge numbers of objects, I
have not found object _creation_ to be a real issue. Managing the data
structures to keep track of all those objects is where I often see the
hit. You won't be eliminating the time it takes to allocate an object,
just replacing it with something else. You'll have to do all the things
the malloc implementation is already doing, and hope to be able to do
it much faster.
Just thinking about it in my head, it would seem like you could create
a static pool in +initialize, use that pool to grab instances in
+alloc, and in -dealloc, don't call super. Instead, call a utility
class method for returning the object to the pool. BTW, remember that
programmers expect instance variables to be zeroed out, which of course
wouldn't be the case with the pooled objects.
Cheers,
tim
_______________________________________________
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.