From: Arno P. <ar...@pu...> - 2011-01-21 21:10:48
|
On 1/21/11 12:25 PM, Panayotis Katsaloulis wrote: > > On Jan 21, 2011, at 9:46 PM, Arno Puder wrote: > >> >> You are right: so-called convenience methods in Cocoa place the >> newly-created object automatically in the autorelease pool. You can see >> above that we create a temporary autorelease pool that we release again >> immediately. When the GC reclaims the C version of UIButton, it will >> call a finalizer (the __DELETE_* functions) that will do a 'release' in >> the wrapped Objective-C UIButton. > > Isn't expensive to have an autorelease pool for every possible convenience selector of ObjC? > (not only constructors...) Autorelease pools are expensive, yes. Please note that we already do exactly the same thing in the Objective-C backend because the reference counting algorithm used there does not know about autorelease pools. So, this is not a specific problem of the C backend, but a general problem. > Apart from that, since there *are* times that GC won't collaborate perfectly with autoreleased objects (like the situation I mentioned before with delayed animations ), is there a "backup plan" in the C backend to handle and fine tune the current memory management? (i.e. by using something like retain/release) ? I don't know about the delayed animation API, but I'm sure it can be handled. It might also be possible to be more efficient with the creation of autorelease pools, but I first want to have a working C backend before starting with optimizations. Arno |