El 04/07/2008, a las 11:38, Jean-Daniel Dupas escribió:
I don't see your point.
Using standard memory management, you can create you own pool, and
using GC, you can manually trigger the GC. What prevent you to avoid
memory peak ?
Bonjour, Jean.
Try it yourself. With the correct use of an autorelease pool you can
turn a simple loop to hog all memory resources to not use any
perceivable amount of memory. It is exactly as this because it was
designed this way.
However, this is hardly possible with GC even if you trigger the GC
manually in the middle of the loop. It simply will not release the
memory at the rate you expect because it follows its own rules and as
far as free memory is available it will not free anything unless it is
a reason, according to its algorithms, to do so. Furthermore, the fact
that the memory is released in a parallel threat running at lower
priority, allows for little chance that the memory you would like to
be released at a particular point, actually gets released on time.
When things go really bad, the GC simply stops the app (in a user
noticeable way) until it has been able to free enough resources for
the app to continue. I might add that I really hate this, and this is
why I turned back to retain/release in my Cocoa development.
Look at it the way you want, but you simply won't have control of the
memory resources used by your app in a GC environment. Just keep a
look at Activity Monitor and compare the memory usage of similarly
complex apps, running on GC and not. Usually the difference is huge.
On the other hand, a badly designed "normal" application can
eventually consume a lot more than a GC enabled app. But my point is
that you *can* control it and you can keep it down, however you
*can't* in a GC App. My point is also that it is not *that* hard to
deal manually with your app resources given the clever release/
autorelelase/retain features of Cocoa. However, it is true that GC
will always keep global memory usage in control (in all cases), and
will never crash the app for that reason, because it is obviously
designed to do so.
You cannot compare iPhone with a desktop/laptop computer. That's not
the only facility Apple has disabled on the iPhone for optimization,
and that does not mean that all thoses features sucks.
Agreed, the iPhone is tiny compared to a desktop computer, and as you
already concede, several features have had to be disabled to keep with
performance requirements. However I didn't want to imply that GC does
suck, It is already a matured technology used by virtually all modern
languages, which can't even be disabled in most of them, and therefore
it is here to stay, and certainly a needed improvement to Cocoa
programming in order to keep with the latest development trends.
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]
