El 03/07/2008, a las 3:33, Michael Ash escribió:
On Wed, Jul 2, 2008 at 6:09 PM, Joan Lluch (casa) <[EMAIL PROTECTED]>
wrote:
Basically, all you have to do is to always return autoreleased
objects from
your methods, and always send release to objects that you created
with alloc
or were returned by any method containing "new" or "copy". Also, if
you only
use the standard accessor methods for setting properties, (which send
release to the old object and retain the new one), you will not
incur in
any memory problem. It should not be that hard, and at the end your
application will potentially perform better, and for sure it will eat
significantly less memory.
I have to object to this bit at the end. It's a common cliche that
garbage collection makes your program perform worse and use more
memory. And certainly this is *possible*. But it's far from a given
these days.
In Cocoa you do lots of retaining and releasing. These operations
aren't free. They involve a lookup into a global hash table and some
sort of atomic increment/decrement operation. They're pretty fast, but
there's certainly some cost there. Garbage collection lets you
eliminate all of this code, so you get a speed bonus there. Whether
this is overcome by the overhead that GC gives you will depend on the
specific program.
The question of memory usage is far from a given, especially in Cocoa
where you do lots of autoreleasing. The pervasive use of autorelease
essentially means that objects don't go away until you go back to the
event loop. This can result in large spikes in memory usage during
event processing. The collector isn't constrained by the event loop
and can run any time it wants to, so it can potentially prevent these
spikes from occurring. This also has a performance impact, as a more
memory efficient program is also a faster program due to having a
smaller working set.
Cocoa's GC also has another interesting advantage: most of the work is
done on a background thread. This means that on any multi-core machine
(which is any Mac sold in the past couple of years) that isn't already
loaded at 100%, this bulk of the GC work essentially comes "for free".
Now, this is not to say that GC will make your program go faster. This
will depend greatly on exactly how your program is designed and
implemented. But while GC won't automatically make your program go
faster, it also won't automatically make it go slower.
Mike
There is a couple of points I think you are missing here.
First, GC makes programs go slower not because of the overhead of the
garbage collection itself, which I concede that may be comparable to
the retain/release calls in a non-managed environment, but for the
extra memory overhead that it is used. The crucial difference between
a non-managed app and a GC app is that in a non-managed app the memory
is released very soon after the life of an object has expired.
Yes, you are right that Cocoa does produce memory usage peaks (though
you are not fair by not saying that you can eliminate them with a
proper use autorelease pools), but in a GC collection environment
these peaks not only are much bigger, but you don't have any means to
avoid them. The problem with GC is that memory used by the app will
eventually suck all the available resources of the system, and from
this to severe performance issues due to virtual memory page faults,
there is only a very short path. However, all of this problems can be
effectively avoided by the traditional self-managed memory Cocoa
programming. The brain cost of having to set some release/retain
messages here and there, does compensate in my opinion (and
experience) the unknown performance issues that a GC app will have as
it is run in a system with limited memory resources. GC works just
fine if you have lots of memory, but not if you have limited
resources. And know think about why Apple did not implement GC in the
iPhone SDKs.
Joan Lluch (casa)
_______________________________________________
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]
