I not be fully informed on the original issue, but I think the source of
this question has to do with an application (WarmStartServer) that will
be
encoding a very large list of elements to transfer to another process
in one
large message. Let's say that the size of the element list we are
encoding
is about 50M in memory and we call NSArchiver to encode this. At our
application level, we don't have a loop to put a pool within (though
one of
some form certainly exists within NSArchiver to walk and encode the
list).
We are just making a single call with a root object that will cause a
lot of
encoding to happen and generate temporary memory usage that greatly
exceeds
the original size of what we are encoding. Putting a pool around the
encodeRootObject: call will be closing the gate after the memory has
been
allocated :-)
I think our choices to work around this problem are:
1. Try putting autorelease pools in the encodeWithCoder: methods of our
objects that are being encoded within the list and see if this solves
the
problem. This should work if the majority of the memory allocation is
happening in these methods.
2. Break up the list into smaller portions to encode and send. This may
be
complicated by the fact that we sometimes want to perform this same
encoding
and write it to disk instead of send it to another process. It would be
much
cleaner, in both cases, to just encode one big blob.
3. Go into the NSArchiver code (or write categories for it) that will
use
autorelease pools during the execution of its existing logic.