[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documentation Bug?

From: Richard Frith-Macdonald
Subject: Re: Documentation Bug?
Date: Fri, 17 Jun 2005 11:28:16 +0100

On 2005-06-17 10:48:15 +0100 Richard Frith-Macdonald <address@hidden> wrote:

On 2005-06-17 10:22:46 +0100 Patrick McFarland <address@hidden> wrote:

 #gnuste thinks implementing
+new yourself instead of using NSObject's implementation is retarded. If people wanted speed they wouldn't be using +new in the first place.

Complete digression but ...

Forgot to say ... I don't know where you got this idea, but it's simply wrong (well ... *some* people might avoid +new, but it's wrong to imply that all/most do, and those who do are probably misguided).

People avoid the autoreleasing constructor methods for performance, (since the autorelease system produces quite an overhead), and use +new with an explicit release instead. Autorelease is a pretty well known performance hit which actually makes people tend to prefer using +new or +alloc/-init as a first attempt at boosting performance, particularly in tight loops.

They may think they can do better than using +new, by calling allocation/initialisation explicitly themselves, but often classes may have optimised the standard methods like +new to do the most efficient possible job excluding the case where everything is inlined. For instance, +new may be retaining and returning a cached object .. in which case it probably faster than an allocWithZone:/init sequence (where the alloc might create an object, and the init might deallocate it and replace it with the value from the cache).

So, avoiding the use of +new for performance is something that a sensible programmer would only do if high level optimisation had already been done and profiling (or some other technique) actually showed them that better alternatives existed for particular cases. It comes in there at the same sort of optimisation level as caching method implementations ... something thats either a last resort after all high level optimisation has failed, or done because you just have to get the last little bit of performance for some reason.

Incidentally, with the gnu runtime (not with the apple runtime), it's probably worth caching class pointers before you start caching implementations of class methods ... that's because the gnu runtime requires an extra lookup to find the class when you do [NSString new] rather than [pointerToStringClass new], and the overhead of this lookup is greater than the method dispatch overhead (though current runtime is immensely faster than old versions at this).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]