On Thu, 17 Nov 2011 12:40:32 +1100, Graham Cox graham@bigpond.com said:
So which were you, Kon or Bal?
(Those of use with extremely long memories might get the reference ;-)
I get the reference, and I resent the implication! :) m.
--
matt neuburg, phd = m...@tidbits.com,
Using properties significantly increased the size of my executable
file. If I had something like this:
float a = [self foo: self.scale];
float b = [self bar: self.scale];
I could cut down the size of my code quite a bit by caching the return
value of self.scale:
float theScale = self.scale;
On Nov 16, 2011, at 01:00 , Don Quixote de la Mancha wrote:
Using properties significantly increased the size of my executable
file. If I had something like this:
float a = [self foo: self.scale];
float b = [self bar: self.scale];
I could cut down the size of my code quite a bit by
One other advantage to using properties over direct ivar access internally is
KVO compliance.
Usually I prefer to declare properties backed by ivars of a different name,
then use getters/setters everywhere except inside initializers and dealloc.
Frees me from having to worry about
On Nov 16, 2011, at 1:00 AM, Don Quixote de la Mancha
quix...@dulcineatech.com wrote:
Using properties significantly increased the size of my executable
file. If I had something like this:
float a = [self foo: self.scale];
float b = [self bar: self.scale];
I could cut down the size of
On Wed, Nov 16, 2011 at 8:03 AM, Kyle Sluder kyle.slu...@gmail.com wrote:
On Nov 16, 2011, at 1:00 AM, Don Quixote de la Mancha
quix...@dulcineatech.com wrote:
Calling accessors is also quite slow compared to a direct iVar access,
because it has to go through Objective-C's message dispatch
On Nov 16, 2011, at 9:31 AM, Don Quixote de la Mancha
quix...@dulcineatech.com wrote:
I've been trying to beat these arguments into the heads of my fellow
coders since most of you lot were in diapers. Just about always the
responses are that Premature Optimization is the Root of All Evil,
On Nov 16, 2011, at 10:31 AM, Don Quixote de la Mancha wrote:
I've been trying to beat these arguments into the heads of my fellow
coders since most of you lot were in diapers. Just about always the
responses are that Premature Optimization is the Root of All Evil,
as well as that programmer
On Wed, Nov 16, 2011 at 10:29 AM, Preston Sumner
preston.sum...@gmail.com wrote:
Can you confirm that the reason the particular software you use is huge,
bloated, and slow is specifically because of objc_msgSend() and not
shortcomings in the application's design or the addition of new,
On Nov 16, 2011, at 9:31 AM, Don Quixote de la Mancha wrote:
Despite that I implemented my own most time-critical routine in C,
objc_msgSend takes up two percent of my run time. I expect it would
be a lot more if I didn't implement that grid update routine in C.
Definitely. Time-critical
On 16 Nov 2011, at 11:31 AM, Don Quixote de la Mancha wrote:
objc_msgSend is slow as Alaskan Molasses compared to a simple C function call.
Cocoa uses Objective-C for I/O and user-interaction libraries, to respond to
events that take place over periods of milliseconds.
For those purposes, I
On Nov 16, 2011, at 10:52 AM, Don Quixote de la Mancha wrote:
Did you ever use any of the early releases of Mac OS X? It was so
slow as to be largely unusable until 10.3 (Panther).
I was working on OS X at that time. The main reasons for poor performance
weren’t micro-level stuff like
On 11/16/11 9:31 AM, Don Quixote de la Mancha wrote:
End-user time is even more expensive than programmer time.
Clearly if you are writing an operating system or other
performance-critical software it's exceedingly important to optimize
things are far as possible. One reason that the iPhone and
On Nov 16, 2011, at 9:31 AM, Don Quixote de la Mancha wrote:
According to Instruments, my iOS App now spends about half its time in
a C (not Objective-C) void function that updates the state of a
Cellular Automaton grid, and the other half in a low-level iOS Core
Graphics routine that fills
On Nov 16, 2011, at 11:52 AM, Don Quixote de la Mancha wrote:
On Wed, Nov 16, 2011 at 10:29 AM, Preston Sumner
preston.sum...@gmail.com wrote:
Can you confirm that the reason the particular software you use is huge,
bloated, and slow is specifically because of objc_msgSend() and not
On 17/11/2011, at 4:31 AM, Don Quixote de la Mancha wrote:
You all speak as if you think I'm a clueless newbie, but I was a
White Badge Senior Engineer in Apple's Traditional OS Integration
team from 1995 through 1996. For most of that time I worked as a
Debug Meister, in which I isolated
On Sun, 13 Nov 2011 01:42:07 -0600, Charles Srstka cocoa...@charlessoft.com
said:
On Nov 13, 2011, at 1:16 AM, ico wrote:
However, I just wonder, is it really true that there is no ANY different
between explicitly declaring iVars and not delaring it?
If youre 64-bit only (or if you
If you’re 64-bit only (or if you require Lion or better), there’s no real
reason to explicitly declare the ivars these days.
As others have pointed out, this is not true. There are practical differences
between declaring and not declaring the ivar explicitly. I almost never
declare the ivar
On Nov 15, 2011, at 9:48 AM, Torsten Curdt wrote:
If you’re 64-bit only (or if you require Lion or better), there’s no real
reason to explicitly declare the ivars these days.
As others have pointed out, this is not true. There are practical
differences between declaring and not declaring
In four words: Fragile Base Class Problem.
The problem is that a subclass (in 32 bit OS X) needs to know the size of the
superclass so it know how to lay out its ivars. If there is no explicit
ivars, there is no way for the compiler to know the size (since when it is
compiling the
On Nov 15, 2011, at 8:44 AM, Torsten Curdt tcu...@vafer.org wrote:
In four words: Fragile Base Class Problem.
The problem is that a subclass (in 32 bit OS X) needs to know the size of
the superclass so it know how to lay out its ivars. If there is no explicit
ivars, there is no way for
Think of it like the compiler generates the ivars from the property
definitions. So the ivar would be indeed explicit ivars - just not
defined as such in the classic way.
Doesn't matter. The subclass still needs to know the size of its superclass
so that it generate the proper ivar offsets.
On Nov 15, 2011, at 9:52 AM, Torsten Curdt tcu...@vafer.org wrote:
Think of it like the compiler generates the ivars from the property
definitions. So the ivar would be indeed explicit ivars - just not
defined as such in the classic way.
Doesn't matter. The subclass still needs to know the
On Nov 15, 2011, at 9:55 AM, Kyle Sluder wrote:
FWIW I check on the llvm IRC channel and the response was I wouldn't
be surprised if there are annoying edge cases, but offhand I don't see
any reason it couldn't be done.
If it could've been done, they would have done it. The fragile base
On Nov 15, 2011, at 10:34 AM, Torsten Curdt wrote:
No it can't. @property only says I have methods named -foo and -setFoo:.
It implies absolutely nothing about storage.
How does
@property (nonatomic, assign) IBOutlet NSWindow *window;
not have the information that there would need to
On Nov 15, 2011, at 10:34 AM, Torsten Curdt wrote:
How does
@property (nonatomic, assign) IBOutlet NSWindow *window;
not have the information that there would need to be an ivar
NSWindow *window;
on 32-bit?
There’s no requirement that there be such an ivar, only a method named
There’s no requirement that there be such an ivar, only a method named
-window that returns an NSWindow*. The implementation of that method is
arbitrary. For example it might just look like
- (NSWindow*) window { return [_parent window];}
But then again the compiler would know about these
On Tue, Nov 15, 2011 at 10:54 AM, Torsten Curdt tcu...@vafer.org wrote:
There’s no requirement that there be such an ivar, only a method named
-window that returns an NSWindow*. The implementation of that method is
arbitrary. For example it might just look like
- (NSWindow*) window { return
On Nov 15, 2011, at 10:54 AM, Torsten Curdt wrote:
But then again the compiler would know about these implementations.
No, it wouldn’t. The compiler has no idea how NSDictionary or NSWindow are
implemented. All it knows about them is what’s given in their header files.
(Worse, even if it did
Explicitly declaring your ivars makes them easier to see in the
debugger. Otherwise you have to call the property accessor from gdb's
command line to look at it.
I feel that it's helpful to declare them in any case, so I can
more-easily tell how much memory each of my objects is taking up by
I find that not having explicit instance variable declarations lets me focus
the class interface. I think that focusing on the interface is more helpful in
the long run.
--Richard
On Nov 13, 2011, at 12:16 AM, ico wrote:
If so, is it a better approach that just declare the property and let
The synthesized ivars are private to the class that declares them. So you can
use them as an ivar in that class's implementation, but not in a subclass
implementation. Usually this is not a problem, but if you already have code
that passes the ivar's address in a function call, for example,
For some reason, sometimes my synthesized ivars show up in the debugger as
ivars, and sometimes they don't. Can anyone explain this? I can't remember
whether this is with GDB or LLDB.
On 2011-11-13, at 5:24 AM, Don Quixote de la Mancha wrote:
Explicitly declaring your ivars makes them easier
I am surprise that I just know we do not need to declare instance variables
explicitly when we declare the property and use @synthesize.
That is we do not need a instance variable to be declared that is
corresponds to the property declaration.
look at this blog:
On Nov 13, 2011, at 1:16 AM, ico wrote:
I am surprise that I just know we do not need to declare instance variables
explicitly when we declare the property and use @synthesize.
That is we do not need a instance variable to be declared that is
corresponds to the property declaration.
35 matches
Mail list logo
