Re: EOFault / NSAutoreleasePool

[Matt Rice]

On Sat, Mar 15, 2008 at 9:06 AM, Richard Frith-Macdonald <address@hidden> wrote:
>
>  On 13 Mar 2008, at 17:03, David Ayers wrote:
>
>  >
>  > NAK :-) Try to compare EOFault to an NSDistantObject.  Attempting to
>  > cache the implementation pointer of a method in a different process
>  > and
>  > bypassing forwardInvocation: will not work.
>
>  So ... technically the optimisation in NSAutoreleasePool is clearly
>  unsafe, but in practice it's probably worth keeping it even so (the
>  person who suggested it to me said it had made a 20% performance boost
>  to their code).

I was thinking this optimization looks a lot like the code here..
http://www.mulle-kybernetik.com/artikel/Optimization/opti-3-imp-deluxe.html

I don't see any reason why it couldn't be done in a subclass of
NSAutoreleasePool which is put into the performance library,
applications that have determined they need it where this optimization is safe
can use it, others unfortunately won't see the benefit...

something to consider anyhow.