Re: WTF? How can this work?
Re: WTF? How can this work?
- Subject: Re: WTF? How can this work?
- From: Chris Kane <email@hidden>
- Date: Sun, 19 Aug 2001 11:11:40 -0700
On Sunday, August 19, 2001, at 09:31 AM, Ondra Cada wrote:
John Hornkvist (JH) wrote at Sun, 19 Aug 2001 12:34:11 +0200:
JH> In essence, the problem is that Apple has chosen to implement
NSArray
JH> and NSMutableArray with the same class. I regard this as a bug.
Whew! That *IS* a bug all right. Perhaps I'm starting to have some idea
why
the OS X is that terribly slow and memory-hungry! Especially if they
happened
to use this bright idea for other immutable classes as well :(((
That's a perfectly legitimate implementation decision. Having something
typed "NSArray *" does NOT guarantee that it is immutable, though many
people have this misconception. The effect of the extra memory is a
couple percent. Internal fragmentation due to the 16-byte alignment of
heap-allocated blocks is a much larger effect (~9% in one test I
recall). In 10.1, the memory "loss" and immutability are recovered.
The reason OS X is so memory-hungry, as you put it, is that there are
>50 more frameworks and lots more functionality (though, granted, a fair
bit of it is not directly used by developers, but rather by APIs
developers then use).
Might be also the reason why some of my older code did not work (the
ports
were not important enough to pursue the problems): a few times for me
the
(im)mutability brought information as well, ie. I had code like
id o=...;
...
if ([o isKindOfClass:[NSMutableArray class]]) { ... code A ... }
else if ([o isKindOfClass:[NSArray class]]) { ... code B ... }
...
This is just a bad idea. You should rarely be basing a decision on
whether or not the dynamic runtime type of an object is mutable or not.
You should be coding to the API's contract, as specified by the return
type.
If o=[myView subviews]; and in code A you [o addObject:newView] and in B
you [myView addSubview:newView];, are you going to complain when code A
crashes because you've manipulated the subviews area out from under the
parent view? The pattern above probably indicates a bug most of the
time.
Blast it :(((( Somebody might tell me again how Apple _improved_
OpenStep
:((( And there is not a word of this bloomin' thing in the Foundation
Kit
release notes, or am I blind?
It's clear to me that nobody complaining about Mac OS X 10.0 vs.
OPENSTEP was around for OPENSTEP 4.0, but probably came along later
after 4.2 (or they have short memory). Oy! what a lot of wailing and
gnashing of teeth there was. "It's a memory hog." "App launch is
slow." "The graphics are slow." "Converting my old code is hard" (and
it was much much harder than any Mac OS X transition). [OPENSTEP 4.0
avoided most of the "the new UI sucks" complaints because the new UI was
dropped after pre-release 1 for time-to-market reasons.] The wisdom of
string objects instead of nice fast char *'s was certainly questioned
more than once, and we're still paying the performance penalty for that,
as we always will.
Chris Kane
Cocoa Frameworks, Apple