On Jun 27, 2008, at 12:31 PM, John Engelhart wrote:
Lesson #1: If you have any interest in performance, you must avoid,
at all costs, "writing" to a __strong pointer.
That's almost like saying:
"If you have any interest in performance, you must avoid, at all
costs, using a high level language like C."
It's only true if you ignore other things that are also both true, and
that many consider to have a higher priority. For one, using higher
level languages and libraries allows us to be more productive and to
build software that delivers more functionality while at the same time
being easier to maintain.
-(BOOL)doSomething:(id)obj error:(NSError **)error
{
if(error != NULL) { *error = NULL; } // Make sure we clear the
error object
}
It's sort of ambiguous as to what should be returned by the indirect
error pointer on the condition of success. I could think of several
neat ideas if the expected behavior were defined up front, even
requiring the caller to initialize the pointer to a default NSError
singleton and allowing errors to accumulate in a stack like
fashion. Alas, the only clearly defined behavior is that one
failure, a NSError object is indirectly returned.
The relevant documentation is found here:
<http://developer.apple.com/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/chapter_4_section_4.html#//apple_ref/doc/uid/TP40001806-CH204-SW5
>
If you have suggestions for improvements, please file formal
enhancement requests.
The write barrier penalty is substantial. I benchmarked a tight
loop that called a function that did nothing but the naive clearing
of the value. The result (on a 1.5GHz G4) was that it was 2429.55%
(or, over 24 times) slower with -fobjc-gc enabled. So, best to
avoid updating a __strong pointer at any and all costs.
If you're a developer who cares about performance, your #1 priority is
to implement the actual functionality. Your #2 priority to run
meaningful benchmarks. Your #3 priority to address any performance
problems that you find, in order of severity.
Synthetic / micro benchmarks are typically of limited value. Most
Cocoa application developers will find that their performance problems
are higher level and more algorithmic in nature, rather than on this
very low level.
typedef struct {
NSString *aString;
__weak NSString *aWeakString;
NSInteger anInteger;
} MYStructType;
MYStructType globalStructTypeArray[42]; // <-- Global!
<snip>
The pointer to 'aString' in the above (or any of my other __strong
pointers in my actual code) were clearly not being treated as
__strong, and the GC system was reclaiming them causing all sorts of
fun and random crashes.
Bugs are bad, and if you think that you have found one, it would be
great if you could file a formal bug report.
That said, this is Cocoa-Dev, and the code above has very little to do
with Cocoa / Objective-C development in practice.
Most Cocoa developers will find that Garbage Collection works
absolutely fine, and that runtime performance is about the same
(sometimes better, sometimes worse) compared with using manual memory
management.
j o a r
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
