On 30 Nov 2009, at 21:33, Ben Haller wrote:

> On 30-Nov-09, at 4:06 PM, Bill Bumgarner wrote:
> 
>> On Nov 30, 2009, at 12:50 PM, Dennis Munsie wrote:
>> 
>>> Not that I'm advocating it, but you can also declare a field as @public to 
>>> allow you to access it via the -> operator.  Of course, I could be missing 
>>> some compiler magic going on behind the scene as well, and it may not 
>>> actually be the same speed wise as @defs was.
>> 
>> The compiler preserves the "non-fragile" part of "non-fragile ivars" when 
>> using the -> operator.
>> 
>>> Not to mention that it's just plain nasty :)
>> 
>> Yup, that it is.
> 
>  This is interesting to me, since I am in fact using @public and -> with some 
> ivars to allow faster use of one of my classes.  (Yes, I've confirmed that 
> this is significant in Sampler; it is, in fact, quite a large percentage of 
> the total time of my app, which has runtimes measured in days, so I do care 
> :->).  I understand the concept of the fragile base class problem and so 
> forth; I just didn't realize Apple had done something to fix it that might 
> affect the performance of my app.  :->
> 
>  What I want is essentially a struct with methods; I need super-fast access 
> to ivars for clients of the class in some places in my code.  But I also want 
> functionality provided by the class itself via methods, and I want a class 
> hierarchy (so just using functions instead of methods gets ugly fast).  Is 
> there a better solution than @public?  Or is there some reason I shouldn't 
> worry about it -- is all the overhead just on the first pass through any 
> given code path, with back-patching, for example?
> 
>  I realize the dangers of breaking encapsulation, etc.  :->  But sometimes 
> optimization simply demands that you do such things.  I run my app on a 
> computing cluster, and time on the cluster is at a premium, so the headaches 
> involved are worth it.  I just want to know the best way to do it, given 
> these recent changes to Objective-C.  Any advice?

Could your class perhaps expose a struct or a pointer to it as a property of 
some kind? You are avoiding touching instance variables, and once the method to 
retrieve the struct is used, you can cache the result. Or even, expose the 
struct as an instance variable, giving the speed advantage of 
both._______________________________________________

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 arch...@mail-archive.com

Reply via email to