Le 4 juil. 08 à 11:25, Joan Lluch (casa) a écrit :



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.

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 ?



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.

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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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]

Reply via email to