Kevin Glass wrote:
> We're currently using the java to iphone objc library and finding
> performance issues with the default option of having an AutoReleasePool
> for every class/method. We're focusing on games at the moment so we're
> finding that the only class we want the pool in is the main class
> managing the game loop and then applying the annotation
> NoAutoReleasePool to every other class to let auto the garbage
> management happen on the release at the end of the game loop.
Right now we only support the annotation NoAutoReleasePool that can only
be added to methods. I was thinking of introducing more annotations
where you could set a default setting for a whole class. Requires some
work, but certainly might be more convenient.
> Is it advised to have so many auto release pools since they seem to have
> a high performance overahead.
Giving every method its own auto release pool certainly introduces high
overhead. Let me digress a little and write about the implication of
using the NSAutoReleasePool for garbage collection. It should be clear
that we cannot identify circular data structures with this, since the
reference count never drops to 0 in this case. I don't see this as a
problem, but you need to be aware of this when designing your data
structures.
But there is another problem that we cannot deal with in a good way.
Imagine the following code:
void foo()
{
for (int i = 0; i < 10000000; i++)
new String();
}
When this code gets cross-compiled, those 1000* objects would all end up
in the auto release pool of method foo. Those objects would only get
deleted when you exit foo. A normal garbage collector would of course be
able to reclaim memory while the for-loop still executes. These are some
implications for using the NSAutoReleasePool and not have a full-fledged
garbage collector.
Coming back to your question: of course it is a huge overhead of adding
an auto release pool to every method and in many cases, it is not really
necessary (e.g., when no objects are being allocated inside a method).
The problem is, that this cannot really be easily determined
automatically. What if a method (that itself does not instantiate
objects) calls another method (that does instantiate objects)? Perhaps
there are some good heuristics that can be implemented inside of XMLVM,
but for the moment we take the easy way of letting the developer give
'hints' via the NoAutoReleasePool annotation.
Suggestions are welcome!
> Still going great here tho :) (Patch is in progress again)
:-)
Arno
|
