Re: ARC vs Manual Reference Counting
On Sep 11, 2013, at 10:38 , John McCall rjmcc...@apple.com wrote: [reduced need for Café Macs dinner tickets] Fortunately. :) But you do know where to get them anyway…? ;-) [inline reference counts] Right. ARC doesn’t replace the benefit of having an inline reference count. I think if we could magically bless all objects with an inline reference count without worrying about disrupting existing hard-coded object layouts, we probably would. I can think of 3 ways, which you obviously never have thought of yourselves, because you guys just don’t bother with that sort of thing... *g*: 1. Non-fragile ivars, just insert one where you want it Problem there is probably that ivars aren’t as non-fragile in practice as we’d like. In addition, a whole word might be a bit much, especially when you already have an inline refcount tucked away somewhere else. 2. IV() trick Just tack it on at the end of each object that wants one…problems with class-size not reported correctly (we’re looking at you, CoreFoundation) and custom allocs. 3. 3 bits in the class pointer Since we aren’t allowed to get the isa pointer directly these days anyhow, that means we can mask out the low-order bits in object_getClass(), objc_msgSend() and the non-fragile ivar access code..hhmmm. Number of bits depends on whether you just rely on alignment or also grab what’s there from malloc() bucketing (probably shouldn’t). The “Getting Reference Counting Back into the Ring” paper claims that with 3 bits of recount, you avoid overflow for 95% of objects, so that would be pretty good. Of course, automagic isn’t necessarily a requirement, so my favorite is: 4. Do it yourself assistance How about a function that takes a pointer to wherever I stashed my reference count and did all the right things, for example wrt. weak references? Or a macro. Did I mention this one’s my favorite? [opting local variables out of ARC using __unsafe_unretained] Absolutely. We’ve found that it usually doesn’t take very many __unsafe_unretained annotations to eliminate most regressions. There are a ton of places where any human reading the code would immediately realize that an object won’t get released, but ARC can’t quite prove that, usually because there’s an intervening message send. There’s a bunch of interesting research again on region analysis and proving things statically, now that the practical limitations of copying collectors are becoming more widely appreciated (see also all the off-heap stuff going on in Java-land). Rust is also interesting the way it puts in some programmer involvement in declaring intent, but then helps with making sure that this intent isn’t violated. Most of those places don’t detectably affect performance; it’s the one or two that happen in a loop and therefore trigger 40,000 times that you notice. But by the same token, those sites tend to show up in Instruments and so are easy to track down and fix. The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you don’t notice, the flat profiles, are in some ways more insidious, as they drag everything down just a bit. Along with all the other things that drag everything down a bit, and soon enough you have something that’s 10% or 2x or 10x slower than it needs to be and no obvious culprits. Cheers, Marcel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you don’t notice, the flat profiles, are in some ways more insidious, as they drag everything down just a bit. Along with all the other things that drag everything down a bit, and soon enough you have something that’s 10% or 2x or 10x slower than it needs to be and no obvious culprits. Yes, this is definitely a problem, and an unsolvable one at that. Not necessarily. Recently, on IBM z/Architecture platform, some JNI code I wrote ended up showing a bunch of unremarkable flat profiles when captured with hardware instrumentation at various intervals. Looking for any possible performance improvements, I examined the code associated with each unremarkable profile, and found some routines that were being called unnecessarily (returned after a quick condition check); when the logic was changed so as to avoid the checks (which was quite unobviously called from a loop) there was a 40% improvement in CPU performance. You might be surprised what you can find by looking at those flat profiles. Paul 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 13, 2013, at 3:04 AM, Marcel Weiher marcel.wei...@gmail.com wrote: On Sep 11, 2013, at 10:38 , John McCall rjmcc...@apple.com wrote: [inline reference counts] Right. ARC doesn’t replace the benefit of having an inline reference count. I think if we could magically bless all objects with an inline reference count without worrying about disrupting existing hard-coded object layouts, we probably would. I can think of 3 ways, which you obviously never have thought of yourselves, because you guys just don’t bother with that sort of thing... *g*: 1.Non-fragile ivars, just insert one where you want it Problem there is probably that ivars aren’t as non-fragile in practice as we’d like. In addition, a whole word might be a bit much, especially when you already have an inline refcount tucked away somewhere else. 2.IV() trick Just tack it on at the end of each object that wants one…problems with class-size not reported correctly (we’re looking at you, CoreFoundation) and custom allocs. Right, both of these are very difficult because of widespread code that assumes things about the layout of objects. Also, adding extra fields to objects could easily push them over allocation quanta. It’s a hard problem. 3.3 bits in the class pointer Since we aren’t allowed to get the isa pointer directly these days anyhow, that means we can mask out the low-order bits in object_getClass(), objc_msgSend() and the non-fragile ivar access code..hhmmm. Number of bits depends on whether you just rely on alignment or also grab what’s there from malloc() bucketing (probably shouldn’t). The “Getting Reference Counting Back into the Ring” paper claims that with 3 bits of recount, you avoid overflow for 95% of objects, so that would be pretty good. We’ve certainly looked into things like this. Of course, automagic isn’t necessarily a requirement, so my favorite is: 4.Do it yourself assistance How about a function that takes a pointer to wherever I stashed my reference count and did all the right things, for example wrt. weak references? Or a macro. Did I mention this one’s my favorite? You’re certainly welcome to file a radar asking for an SDK feature like that if you haven’t already. [opting local variables out of ARC using __unsafe_unretained] Absolutely. We’ve found that it usually doesn’t take very many __unsafe_unretained annotations to eliminate most regressions. There are a ton of places where any human reading the code would immediately realize that an object won’t get released, but ARC can’t quite prove that, usually because there’s an intervening message send. There’s a bunch of interesting research again on region analysis and proving things statically, now that the practical limitations of copying collectors are becoming more widely appreciated (see also all the off-heap stuff going on in Java-land). Rust is also interesting the way it puts in some programmer involvement in declaring intent, but then helps with making sure that this intent isn’t violated. The trouble is that Objective-C is essentially immune to non-heuristic static analysis, not just formally but in practice as well. People can and do dynamically add and replace methods on classes, use isa swizzling to change the class of an existing object, and so on, all of which individually make interprocedural region analysis impossible. Most of those places don’t detectably affect performance; it’s the one or two that happen in a loop and therefore trigger 40,000 times that you notice. But by the same token, those sites tend to show up in Instruments and so are easy to track down and fix. The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you don’t notice, the flat profiles, are in some ways more insidious, as they drag everything down just a bit. Along with all the other things that drag everything down a bit, and soon enough you have something that’s 10% or 2x or 10x slower than it needs to be and no obvious culprits. Yes, this is definitely a problem, and an unsolvable one at that. John. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 13, 2013, at 11:51 AM, Paul Scott psc...@skycoast.us wrote: The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you don’t notice, the flat profiles, are in some ways more insidious, as they drag everything down just a bit. Along with all the other things that drag everything down a bit, and soon enough you have something that’s 10% or 2x or 10x slower than it needs to be and no obvious culprits. Yes, this is definitely a problem, and an unsolvable one at that. Not necessarily. Recently, on IBM z/Architecture platform, some JNI code I wrote ended up showing a bunch of unremarkable flat profiles when captured with hardware instrumentation at various intervals. Looking for any possible performance improvements, I examined the code associated with each unremarkable profile, and found some routines that were being called unnecessarily (returned after a quick condition check); when the logic was changed so as to avoid the checks (which was quite unobviously called from a loop) there was a 40% improvement in CPU performance. You might be surprised what you can find by looking at those flat profiles. Sorry, I did not mean that analyzing flat profiles is generally unsolvable, just that when the overhead imposed by ARC is evenly distributed across many call sites, there isn’t an obvious way for a user to recover that performance. John. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 11 Sep 2013, at 19:59, Louis Gerbarg lgerb...@gmail.com wrote: The world is a very different place than it was then, in the 80s RAM was a lot faster relative to the CPU. There is absolutely no way something like you describe today could be done today, most deeply pipelined OoOE CPUs can barely forward a register in 1 CPU cycle. Getting out to L3 cache is often on the order of 20-40 cycles depending on the part, and main memory can literally be hundreds of cycles. Algorithms designed to work in an environments with single cycle ram access simply don't hold up on modern pipelined cache coherent multi-process systems where the processing logic runs at significant multiples of the memory. This is indeed true, but where there's a will there's a way and what we are talking about is relatively simple compared to some of the awesome hardware already out there. I don't think this is the reason it hasn't been done, I think it's more to do with what you'd have to do with the Unix Kernel and friends to make it work. It would make a lot of code incompatible which is bad news and it would also cost a fortune. Besides there are two ways (at least) of doing this, one is super fast and would be very difficult/impossible to implement as per your comment above. But there is another way that is not so fast, but would still be much faster then main CPU doing it and it would also have leak detection. But its not going to happen to pointless talking about it. If Apple were to implement something like this I think there would be a massive increase in performance and reliability Nothing personal, but I think you’re falling into the common fallacy of thinking that Apple engineers are naive and/or ignorant. It happens all the time on these lists. In general, you should assume that the people working on system software are pretty damn smart and experienced, and are aware of all the techniques that an interested but non-expert outsider would know of. If they’re not using them, there’s probably a good reason for it. I'm sure the engineers are a mixture of good, mediocre, and not so good the same as any where else, why should Apple be different? But engineers don't get much say on what projects/features are implemented (especially somewhere like Apple, MS or any of the big 5 technology companies). If you mean user features then sure, often engineers have little say. If you mean runtime and developer features then you are wrong, the developers at Apple have a lot of say in how what happens. Tim Cook and Phil Schiller didn't sit down in a meeting and say Let's implemented tagged pointers, users will love those, and yet somehow we have them ;-) This is true too, but only because they sold it to them and it just happened to fit in with what they wanted. I'm not saying the engineering department doesn't come up with wonderful features but I've seen really cool products dropped at Apple and other places simply because it wasn't in the direction the current upper management of the company wanted to go at the time and had nothing to do with how good or bad the underlying technology was. Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Hi John! On Sep 10, 2013, at 19:26 , John McCall rjmcc...@apple.com wrote: On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote: [Optimizations in ARC are there to mitigate pessimizations] For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Glad to hear that the performance problems that the optimizations were designed to mitigate were identified early, hope this also resulted in fewer Café Macs dinner tickets. :-) Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. I don’t think that would be a good target or reason for opting out. In fact, I have a protocol where I have a +1 return that I am thinking of turning ARC on for so I don’t have to do that any longer. :-) More likely performance reasons/targets for opting out are things like inline reference counts and, especially, object caches. For me they generally bring factors of improvement, if not orders of magnitude, when applicable (wasn’t it CoreGraphics that had problems with their object cache no longer working on GC, thus killing performance?) Being able to mix-n-match and opt out is definitely one of the awesome features of ARC. On the inline reference counts: when I was doing my recent tests on archiving performance, I suddenly found that object creation (1M objects) was taking longer than expected. Adding an inline retain count *halved* the running time for creating the object graph (155ms vs 300ms)! I have to admit I was bit surprised that the difference would be this big, considering the intrinsic cost of object creation.(Out of curiosity I tested it with ARC and it took 400ms) Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases workarounds like literally making every temporary variable a property is basically asking to be pessimized. You misunderstand (I am likely blame for that for not expressing myself clearly): the temporary variables I use accessors for are the (very few) ones that have strange enough lifetimes that you see retain/release code for them in the middle of methods. Quite often, they already live in instance variables, but are just accessed in an ad-hoc fashion. Using accessors for them really is (or should be) a no-brainer. Sometimes there are asynchronous loops that use a local variable in a similar fashion. Using instance variables for ALL method temporaries would be silly…in essence it would be using the ARC strategy, but without the optimizer running to get rid of most of the damage, ouch! Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, That is also what I would have expected, given what I know about it. It’s interesting that the “group consensus” I find both on the webs/tutorials and also here, sometimes tacit, sometimes not, is that ARC is a performance win. Note how the claim that ARC was faster went unremarked, whereas the finding of a slowdown created immediate negative reaction (“did you test?”, “you must have made a mistake”), fortunately mostly in good humor. and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? Ultimately, ARC is just a tool for improving your productivity as a programmer, not a magic button with no downsides. ;-) Cheers, Marcel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 11, 2013, at 12:03 AM, Marcel Weiher marcel.wei...@gmail.com wrote: On Sep 10, 2013, at 19:26 , John McCall rjmcc...@apple.com wrote: On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote: [Optimizations in ARC are there to mitigate pessimizations] For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Glad to hear that the performance problems that the optimizations were designed to mitigate were identified early, hope this also resulted in fewer Café Macs dinner tickets. :-) Fortunately. :) Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. I don’t think that would be a good target or reason for opting out. In fact, I have a protocol where I have a +1 return that I am thinking of turning ARC on for so I don’t have to do that any longer. :-) I think we’re in agreement here. More likely performance reasons/targets for opting out are things like inline reference counts and, especially, object caches. For me they generally bring factors of improvement, if not orders of magnitude, when applicable (wasn’t it CoreGraphics that had problems with their object cache no longer working on GC, thus killing performance?) On the inline reference counts: when I was doing my recent tests on archiving performance, I suddenly found that object creation (1M objects) was taking longer than expected. Adding an inline retain count *halved* the running time for creating the object graph (155ms vs 300ms)! I have to admit I was bit surprised that the difference would be this big, considering the intrinsic cost of object creation.(Out of curiosity I tested it with ARC and it took 400ms) Right. ARC doesn’t replace the benefit of having an inline reference count. I think if we could magically bless all objects with an inline reference count without worrying about disrupting existing hard-coded object layouts, we probably would. Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases workarounds like literally making every temporary variable a property is basically asking to be pessimized. You misunderstand (I am likely blame for that for not expressing myself clearly): the temporary variables I use accessors for are the (very few) ones that have strange enough lifetimes that you see retain/release code for them in the middle of methods. Quite often, they already live in instance variables, but are just accessed in an ad-hoc fashion. Using accessors for them really is (or should be) a no-brainer. Sometimes there are asynchronous loops that use a local variable in a similar fashion. Using instance variables for ALL method temporaries would be silly…in essence it would be using the ARC strategy, but without the optimizer running to get rid of most of the damage, ouch! We’ve definitely seen some odd contortions to avoid a few explicit retain/releases. Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, That is also what I would have expected, given what I know about it. It’s interesting that the “group consensus” I find both on the webs/tutorials and also here, sometimes tacit, sometimes not, is that ARC is a performance win. Note how the claim that ARC was faster went unremarked, whereas the finding of a slowdown created immediate negative reaction (“did you test?”, “you must have made a mistake”), fortunately mostly in good humor. and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? Absolutely. We’ve found that it usually doesn’t take very many __unsafe_unretained annotations to eliminate most regressions. There are a ton of places where any human reading the code would immediately realize that an object won’t get released, but ARC can’t quite prove that, usually because there’s an intervening message send. Most of those places don’t detectably affect performance; it’s the one or two that happen in a loop and therefore trigger 40,000 times that you notice. But by the same token, those sites tend to show up in Instruments and so are easy to track down and fix. John. ___ Cocoa-dev mailing list
Re: ARC vs Manual Reference Counting
Le 11 sept. 2013 à 09:03, Marcel Weiher marcel.wei...@gmail.com a écrit : Hi John! On Sep 10, 2013, at 19:26 , John McCall rjmcc...@apple.com wrote: On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote: [Optimizations in ARC are there to mitigate pessimizations] For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Glad to hear that the performance problems that the optimizations were designed to mitigate were identified early, hope this also resulted in fewer Café Macs dinner tickets. :-) Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. I don’t think that would be a good target or reason for opting out. In fact, I have a protocol where I have a +1 return that I am thinking of turning ARC on for so I don’t have to do that any longer. :-) More likely performance reasons/targets for opting out are things like inline reference counts and, especially, object caches. For me they generally bring factors of improvement, if not orders of magnitude, when applicable (wasn’t it CoreGraphics that had problems with their object cache no longer working on GC, thus killing performance?) Being able to mix-n-match and opt out is definitely one of the awesome features of ARC. On the inline reference counts: when I was doing my recent tests on archiving performance, I suddenly found that object creation (1M objects) was taking longer than expected. Adding an inline retain count *halved* the running time for creating the object graph (155ms vs 300ms)! I have to admit I was bit surprised that the difference would be this big, considering the intrinsic cost of object creation.(Out of curiosity I tested it with ARC and it took 400ms) Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases workarounds like literally making every temporary variable a property is basically asking to be pessimized. You misunderstand (I am likely blame for that for not expressing myself clearly): the temporary variables I use accessors for are the (very few) ones that have strange enough lifetimes that you see retain/release code for them in the middle of methods. Quite often, they already live in instance variables, but are just accessed in an ad-hoc fashion. Using accessors for them really is (or should be) a no-brainer. Sometimes there are asynchronous loops that use a local variable in a similar fashion. Using instance variables for ALL method temporaries would be silly…in essence it would be using the ARC strategy, but without the optimizer running to get rid of most of the damage, ouch! Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, That is also what I would have expected, given what I know about it. It’s interesting that the “group consensus” I find both on the webs/tutorials and also here, sometimes tacit, sometimes not, is that ARC is a performance win. Note how the claim that ARC was faster went unremarked, whereas the finding of a slowdown created immediate negative reaction (“did you test?”, “you must have made a mistake”), fortunately mostly in good humor. I think this common misbelief come from the fact that when Apple released ARC, they have claimed a non negligible performance win for retain/release and autorelease operations. While this is true, it does not give any clue about the global impact of ARC. and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? Yes. it works to disable ARC for arguments and other local variables. I managed to reduce the ARC impact a little further by applying it to some arguments in hot paths. -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 11 Sep 2013, at 05:04, Jens Alfke j...@mooseyard.com wrote: On Sep 10, 2013, at 12:33 PM, Dave d...@looktowindward.com wrote: You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). I’ve read through a lot of GC papers in the past, and I’m not sure what you’re talking about here, unless it’s something that allows extra tag bits to be stored in pointers. This was used a lot in old LISP systems; it can be useful with interpreted languages but I don’t think it’d be applicable to a C-based language. (A lot of the more sophisticated GC techniques simply don’t work with C-like code because it’s too low-level and makes too many assumptions about memory. For example, you can’t use compaction or copying collectors at all because objects can’t be relocated. The Obj-C garbage collector had to rely on inefficient conservative mark/sweep algorithms.) This was using aUnix Box/MS-DOS box and it was our own hardware, and yes it worked with C and Assembler (via a set of Macro's). Basically it was a lump of hardware that controlled allocating memory from a pool. It wasn't used for system memory (although it could have been), but as a way of speeding up certain Image Processing operations. Basically it could allocate or free a memory block in one machine cycle - it could also copy or fill a block much faster then the CPU too. If Apple were to implement something like this I think there would be a massive increase in performance and reliability Nothing personal, but I think you’re falling into the common fallacy of thinking that Apple engineers are naive and/or ignorant. It happens all the time on these lists. In general, you should assume that the people working on system software are pretty damn smart and experienced, and are aware of all the techniques that an interested but non-expert outsider would know of. If they’re not using them, there’s probably a good reason for it. I'm sure the engineers are a mixture of good, mediocre, and not so good the same as any where else, why should Apple be different? But engineers don't get much say on what projects/features are implemented (especially somewhere like Apple, MS or any of the big 5 technology companies). (This is a special case of the nearly universal engineer’s fallacy of dismissing any problem you haven’t personally worked on as trivial.) I personally worked on these problems and I don't consider the trivial. Cheers Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 11 Sep 2013, at 11:37, Jean-Daniel Dupas devli...@shadowlab.org wrote: Yes. it works to disable ARC for arguments and other local variables. I managed to reduce the ARC impact a little further by applying it to some arguments in hot paths. -- Jean-Daniel I would have thought that you would get most bang for your buck by optimising decalloc methods? If I've understood what is being said: [someObject someMehtod:,myObject]; Causes the compiler to add extra retains? If so, then, in my experience, dealloc tends to triggers the release of a whole network of dealloc's and if they are all doing the same extra retain calls, then it would surely impact performance? Cheers Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
ARC is a combination of compiler and runtime technologie. The compiler generates call to the runtime, so if you see a lot of ARC specific calls in the profiler, you can know if the impact is due to ARC or not. http://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support Le 11 sept. 2013 à 17:15, Sean Roehnelt s...@yellowmatter.com a écrit : ARC is compile time, not runtime, so I don't see how it could… On Sep 9, 2013, at 1:18 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: And does the profiler explicitly shows that ARC runtime code is the culprit ? -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 11, 2013, at 6:37 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? Yes. it works to disable ARC for arguments and other local variables. And you can put __unsafe_unretained objects in struct declarations, if you feel you must, and ARC won't complain. --Andy ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Wed, Sep 11, 2013 at 6:58 AM, Dave d...@looktowindward.com wrote: On 11 Sep 2013, at 05:04, Jens Alfke j...@mooseyard.com wrote: On Sep 10, 2013, at 12:33 PM, Dave d...@looktowindward.com wrote: You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). I’ve read through a lot of GC papers in the past, and I’m not sure what you’re talking about here, unless it’s something that allows extra tag bits to be stored in pointers. This was used a lot in old LISP systems; it can be useful with interpreted languages but I don’t think it’d be applicable to a C-based language. (A lot of the more sophisticated GC techniques simply don’t work with C-like code because it’s too low-level and makes too many assumptions about memory. For example, you can’t use compaction or copying collectors at all because objects can’t be relocated. The Obj-C garbage collector had to rely on inefficient conservative mark/sweep algorithms.) This was using aUnix Box/MS-DOS box and it was our own hardware, and yes it worked with C and Assembler (via a set of Macro's). Basically it was a lump of hardware that controlled allocating memory from a pool. It wasn't used for system memory (although it could have been), but as a way of speeding up certain Image Processing operations. Basically it could allocate or free a memory block in one machine cycle - it could also copy or fill a block much faster then the CPU too. The world is a very different place than it was then, in the 80s RAM was a lot faster relative to the CPU. There is absolutely no way something like you describe today could be done today, most deeply pipelined OoOE CPUs can barely forward a register in 1 CPU cycle. Getting out to L3 cache is often on the order of 20-40 cycles depending on the part, and main memory can literally be hundreds of cycles. Algorithms designed to work in an environments with single cycle ram access simply don't hold up on modern pipelined cache coherent multi-process systems where the processing logic runs at significant multiples of the memory. If Apple were to implement something like this I think there would be a massive increase in performance and reliability Nothing personal, but I think you’re falling into the common fallacy of thinking that Apple engineers are naive and/or ignorant. It happens all the time on these lists. In general, you should assume that the people working on system software are pretty damn smart and experienced, and are aware of all the techniques that an interested but non-expert outsider would know of. If they’re not using them, there’s probably a good reason for it. I'm sure the engineers are a mixture of good, mediocre, and not so good the same as any where else, why should Apple be different? But engineers don't get much say on what projects/features are implemented (especially somewhere like Apple, MS or any of the big 5 technology companies). If you mean user features then sure, often engineers have little say. If you mean runtime and developer features then you are wrong, the developers at Apple have a lot of say in how what happens. Tim Cook and Phil Schiller didn't sit down in a meeting and say Let's implemented tagged pointers, users will love those, and yet somehow we have them ;-) Louis ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote: On Sep 9, 2013, at 11:33 , Tom Davie tom.da...@gmail.com wrote: On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: And does the profiler explicitly shows that ARC runtime code is the culprit ? Yes, it does. Isn’t it strange how when someone says “oh, and ARC is faster”, without measurements, that passes without comment?\\ I believe you’ve been on this list long enough to know that nothing ever passes without comment. [] The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). It shouldn’t really be surprising. ARC adds an astounding number of additional reference counting ops to all code involving object pointers. If that were compiled, ObjC would be completely unusable and slower than all the so-called scripting languages out there. So for things to be usable, ARC then has the optimizer try to undo most of the damage and finally adds some clever runtime hacks to mitigate the rest. Since the hacks and the remaining damage are somewhat orthogonal, you sometimes end up ahead and sometimes you end up behind. The other thing that should be considered when seeing heroic hacks like the autorelease-undoer is that such techniques rarely arise spontaneously from an idle moment of relaxed performance optimization. More usually, they happen because there is some sort of “ho lee f*k” moment, where performance regression is so bad/project-threatening that something drastic/heroic needs to be done. For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. But most of these micro-optimizations are achievable within ARC by adding a few __unsafe_unretained annotations. Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases workarounds like literally making every temporary variable a property is basically asking to be pessimized. It’s a happy coincidence that, in this case, a better code style corresponds to better performance. Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Ultimately, ARC is just a tool for improving your productivity as a programmer, not a magic button with no downsides. John. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 9 Sep 2013, at 09:30, Kevin Meaney k...@yvs.eu.com wrote: I don't know what it is like to convert an old project, but I would recommend ARC for new projects and I believe the time investment is worthwhile. Kevin If the project is of any size it's the pits! It's not worthing doing unless the Project Memory Management is completely Beswicked! Cheers Dave On 9 Sep 2013, at 09:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/ktam%40yvs.eu.com This email sent to k...@yvs.eu.com ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com This email sent to d...@looktowindward.com ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 10, 2013, at 2:11 PM, Dave wrote: On 9 Sep 2013, at 09:30, Kevin Meaney k...@yvs.eu.com wrote: I don't know what it is like to convert an old project, but I would recommend ARC for new projects and I believe the time investment is worthwhile. Kevin If the project is of any size it's the pits! It's not worthing doing unless the Project Memory Management is completely Beswicked! Cheers Dave FWIW, I like to think of it this way: What's the compelling business reason for the change? Does it justify the effort, time and money you will put in to it? If so, how? If you can't answer those questions clearly with good reasons, then don't spend the time on it. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 10, 2013, at 21:52 , Ken Thomases k...@codeweavers.com wrote: On Sep 9, 2013, at 3:49 AM, Marcel Weiher wrote: The pattern I adopted long ago to avoid that sort of situation is to have an instance variable for my temps, in which case the code becomes: [self setTemp:newObject]; … do stuff … [self setTemp:nil]; or if you prefer dot syntax: self.temp = newObject; … do stuff … self.temp = nil; Even if you forget nilling, you at most have an extended lifetime of an object, not a leak. I also generally do the same in initialization code (but not in dealloc). For me, that simply got rid of reference-counting pain. Completely. Memory management is mediated by accessors, always. And accessors are generated. This technique is not safe for reentrant methods, Hi Ken, I should have been more clear: this technique is not needed for ordinary methods or ordinary local variables. I use it for those types of methods that are run asynchronously and that therefore want to retain a temp. Those sorts of methods are not re-entrant anyhow. Cheers, Marcel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Hi, You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). On 80386's and 486's this made an incredible difference. Leaks could be detected at the point in which the leak occurred (e.g when all references to the object were gone) and either release it or throw an exception. I think the overhead was an 8 bytes descriptor which was help in a private fast store SRAM for those in the know!) for each object allocated. In those days we were limited by the cost of the capacity of the devices. If Apple were to implement something like this I think there would be a massive increase in performance and reliability Cheers Dave On 9 Sep 2013, at 23:45, Patrick Cusack livinginlosange...@mac.com wrote: I appreciate everyone's replies. It was a question asked in complete humility. I agree that computers can do analysis much better than humans and that the less code you write, the less you have to debug, so ARC makes a lot of sense. My question really stemmed from Apple's WWDC lecture which appeared to justify the switch on the flimsiest of grounds, ie no longer having to be confused by [NSString stringWithFormat:] vs [NSString initWithString:] which is a pretty easy memory management rule. As my main application is 32 bit (on account of the Quicktime API), I haven't had much exposure to ARC yet. So I will be upgrading with Mavericks to ARC and AVFoundation. Thanks for all of the comments. Patrick On Sep 9, 2013, at 7:29 AM, Alex Zavatone wrote: On Sep 9, 2013, at 3:58 AM, Tom Davie wrote: On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. I think the big point is that if the compiler can figure out what is no longer needed and can be released, and the compiler can do this (at a reasonable cost to performance), then this is a no brainer. I'm sure there are special cases where you would want to do your own memory management. And in this case, you can always flag the class files to turn off ARC and manage memory yourself. Simply put, not having to worry about this gives more brain stack space to fill up with all the other parts of Cocoa and Objective-C that we need to keep track of and saves valuable developer time since it's now rare to have to deal with manual memory management mistakes. Cheers, - Alex Zavatone ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com This email sent to d...@looktowindward.com ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 9, 2013, at 3:49 AM, Marcel Weiher wrote: The pattern I adopted long ago to avoid that sort of situation is to have an instance variable for my temps, in which case the code becomes: [self setTemp:newObject]; … do stuff … [self setTemp:nil]; or if you prefer dot syntax: self.temp = newObject; … do stuff … self.temp = nil; Even if you forget nilling, you at most have an extended lifetime of an object, not a leak. I also generally do the same in initialization code (but not in dealloc). For me, that simply got rid of reference-counting pain. Completely. Memory management is mediated by accessors, always. And accessors are generated. This technique is not safe for reentrant methods, whether due to multi-threading or on the same thread through (possibly indirect) recursion. An automatic (local) temporary variable is private to that stack frame, while an instance variable is shared across the object, which usually means across many stack frames. Something to keep in mind before adopting this. Regards, Ken ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Hi,
I think that's problem with it and a lot of other things too! Once you get out
of the habit of thinking about memory management, you forget how to do it! How
many people can do long multiplication or division on paper these days?? I
started to do it the other day and had to really think to remember the rules!
The thing that bothers me about ARC is that it is a one-way street source code
wise unless you put #ifdefs all over the place and then you invariably don't
test the other version adequately. I try to make my code as compatible as
possible, e.g for properties I still define a dealloc and set them to nil to
release them. retain and release calls (for locals are harder to do right for
both versions. If Apple had allowed the retain and release method calls as per
Non-ARC but for ARC did nothing. This would at least allow code to be compiled
for both versions.
For CF Objects I usually make them properties and then write getters and
setters to manually CFRetain and CFRelease them.
The really good thing about ARC is that it does away with Auto-Release which is
very good news IMO!
One thing that puzzles me is how ARC figures out how to handle something like
this?
-(NSArray*) someMethod:(NSArray*) someArray andSomeValue:(NSInteger) someValue
{
NSArray * myArray;
if (someValue = 37)
myArray = [[NSArray alloc] init];
else
myArray = someArray;
return myArray;
}
Cheers
Dave
On 9 Sep 2013, at 08:44, Kyle Sluder k...@ksluder.com wrote:
Thirded. I thought I wouldn't like it. As soon as I didn't have to manage
retains and releases of temporary objects, the discipline completely left my
mind. Now whenever I go back to non-ARC code I invariably make a ton of
memory management errors, most of which are caught by the analyzer.
--Kyle Sluder
On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote:
Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d
find weird errors that would be caused by some over-released object. We cut
a ton of code with ARC, and in the end we saw reliability go up and actually
even some performance.
ARC is a win. The only place it really got a bit hairy was CF objects. I
wish ARC would work with them a bit more.
On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote:
They’re a _lot_ easier. It might not look that way when you’re reading about
all the details, or converting existing code, because then you’re focusing
on the rare edge cases. But for the most part when actually coding you can
simply ignore ref-counting. Your code becomes more compact and readable, and
you’re less likely to make mistakes.
Alex Kac - President and Founder
Web Information Solutions, Inc.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/kyle%40ksluder.com
This email sent to k...@ksluder.com
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com
This email sent to d...@looktowindward.com
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 9 Sep 2013, at 09:49, Marcel Weiher marcel.wei...@gmail.com wrote:
The pattern I adopted long ago to avoid that sort of situation is to have an
instance variable for my temps, in which case the code becomes:
[self setTemp:newObject];
… do stuff …
[self setTemp:nil];
or if you prefer dot syntax:
self.temp = newObject;
… do stuff …
self.temp = nil;
Even if you forget nilling, you at most have an extended lifetime of an
object, not a leak. I also generally do the same in initialization code (but
not in dealloc). For me, that simply got rid of reference-counting pain.
Completely. Memory management is mediated by accessors, always. And
accessors are generated.
This is great except that you lose the type information for the Class in
question? A way around it might be to have one Instance Variable and a number
of properties of the Right Type, but you'd have to define these in an
@interface section which would be messy.
e.g.
@interface someClass ()
{
id mTempIVar;
}
@property (nonatomic,retain) NSArray* pTempArray;
@property (nonatomic,retain) NSNumber* pTempNumber;
@end
@implementation someClass
@synthesize pTempArray = mTempIVar;
@synthesize pTempNumber = mTempIVar;
You'd also have to watch out that you didn't reuse the same temp in your
methods.
I toyed with the idea of writing a LocalMemoryManager class:
+(id) allocLocalObjectOfClass:(Class) theClass forInstance:(id)
theCallingObject andMethod:(NSString*) theMethodName;
+(void) releaseLocalObjectsForClass:(Class) theClass andMethod:(NSString*)
theMethodName;
+(void) releaseAllLocalObjectsForClass:(Class) theClass;
You'd call it like this:
NSString* myString;
myString = [[LocalMemoryManager allocLocalObjectOfClass:[NSString Class]
forInstance:self andMethod:__FUNCTION__] initWithString@x];
Place a call to releaseLocalObjectsForClass at end of method to release all
local objects and in dealloc call releaseAllLocalObjectsForClass.
I just couldn't bear the thought of having to use a long wordy method call like
allocLocalObjectOfClass to allocate objects.
I am starting to think that this may explain the (vast) difference in
perception of ARC, at least it’s an explanation I can understand: if you
made the switch to always having reference counting mediated by accessors, RC
goes away as a pain point. If you haven’t, it’s probably a huge pain that
ARC removes.
Agreed I have my own way of handling local storage and use a different pattern,
which, sometimes involves the dreaded goto!
Cheers
Dave
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 10, 2013, at 12:33 PM, Dave d...@looktowindward.com wrote: You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). I’ve read through a lot of GC papers in the past, and I’m not sure what you’re talking about here, unless it’s something that allows extra tag bits to be stored in pointers. This was used a lot in old LISP systems; it can be useful with interpreted languages but I don’t think it’d be applicable to a C-based language. (A lot of the more sophisticated GC techniques simply don’t work with C-like code because it’s too low-level and makes too many assumptions about memory. For example, you can’t use compaction or copying collectors at all because objects can’t be relocated. The Obj-C garbage collector had to rely on inefficient conservative mark/sweep algorithms.) If Apple were to implement something like this I think there would be a massive increase in performance and reliability Nothing personal, but I think you’re falling into the common fallacy of thinking that Apple engineers are naive and/or ignorant. It happens all the time on these lists. In general, you should assume that the people working on system software are pretty damn smart and experienced, and are aware of all the techniques that an interested but non-expert outsider would know of. If they’re not using them, there’s probably a good reason for it. (This is a special case of the nearly universal engineer’s fallacy of dismissing any problem you haven’t personally worked on as trivial.) —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 9 Sep 2013, at 11:15, Kevin Meaney k...@yvs.eu.com wrote: On 9 Sep 2013, at 10:33, Tom Davie tom.da...@gmail.com wrote: Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). One of the things that has changed in the code that I write, is that in manual retain/release I would often use the autorelease class methods for creating an object arrayWith... etc. and think about the placement of autorelease pools. Using ARC I almost never use these class methods for creating an object but instead use alloc init. I don't have a lot of temporary objects hanging around now. I never use autorelease if I can help it. I think this is the route cause of a lot of the problems and why ARC was introduced (apart from it being good anyway). I've seen so many projects written by engineers that didn't understand memory management and couldn't be bothered to learn it, so they used AU instead! Cheers Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. Alex Kac - President and Founder Web Information Solutions, Inc.___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. Alex Kac - President and Founder Web Information Solutions, Inc. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/kyle%40ksluder.com This email sent to k...@ksluder.com ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. Tom Davie ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
As someone who considered garbage collection and decided against it and stayed with manual retain and release at that time. I got along reasonably well with manual retain and release. I have happily moved to ARC for a new project. I spent at least a few days getting my head wrapped around the use of ARC and as mentioned by someone else dealing with CF objects is still a pain. I don't know what it is like to convert an old project, but I would recommend ARC for new projects and I believe the time investment is worthwhile. Kevin On 9 Sep 2013, at 09:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/ktam%40yvs.eu.com This email sent to k...@yvs.eu.com ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
It's something new to learn, but in order to stay current there will always be something new. I'm just porting my software to ARC, and whilst there are one or two gotchas (oversights on my part, leading to leakage), I'm finding it to be an excellent idea. Using ARC (in my experience) leads to lower memory use, fewer leaks (well, as you as you do it properly), and improved ease of maintenance. It's win-win-win-win - and one lose. The one loss? No support for 32bit Macs any more. That's a bit of a headache, and it'll cause me some user loss - but I'm going to have to suck it up if I'm to explore the sunlit uplands of this brave new world. On 9 Sep 2013, at 05:41, livinginlosange...@mac.com wrote: Would anyone agree me that ARC introduces more rules and considerations than previously existed with manual reference counting? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 9, 2013, at 9:44 , Kyle Sluder k...@ksluder.com wrote: Thirded. Countered. :-) I thought I wouldn't like it. I thought I would LOVE it, and when I actually used it was “meh”. Not just the additional rules/complexity when dealing with the C side of things (which I do quite a bit), but more importantly it just didn’t make any difference on the upside, for me. Which surprised me greatly. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Retains and release of temporary objects? Did you do things like the following? id myTemp = [newObject retain]; ...do stuff... [myTemp release] I have to admit that when I saw (client) code like that, I also found it problematic, difficult to understand and regularly peppered with errors. The pattern I adopted long ago to avoid that sort of situation is to have an instance variable for my temps, in which case the code becomes: [self setTemp:newObject]; … do stuff … [self setTemp:nil]; or if you prefer dot syntax: self.temp = newObject; … do stuff … self.temp = nil; Even if you forget nilling, you at most have an extended lifetime of an object, not a leak. I also generally do the same in initialization code (but not in dealloc). For me, that simply got rid of reference-counting pain. Completely. Memory management is mediated by accessors, always. And accessors are generated. I am starting to think that this may explain the (vast) difference in perception of ARC, at least it’s an explanation I can understand: if you made the switch to always having reference counting mediated by accessors, RC goes away as a pain point. If you haven’t, it’s probably a huge pain that ARC removes. Cheers, Marcel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 09/09/2013, at 10:49 AM, Marcel Weiher marcel.wei...@gmail.com wrote: I thought I would LOVE it, and when I actually used it was “meh”. Not just the additional rules/complexity when dealing with the C side of things (which I do quite a bit), but more importantly it just didn’t make any difference on the upside, for me. Which surprised me greatly. Likewise, but whatever the technical pros and cons of ARC, you're all discussing this as seasoned Cocoa devs who are familiar with the manual equivalent. I don't think that's the main reason for ARC (or garbage collection before it). It's really because most other modern OO languages don't require any form of manual memory management, and developers new to Cocoa (and after iOS, they came in their droves) were not expecting to have to deal with it. Manual MM looks old-fashioned to those developers and its unfamiliarity led to many mistakes. Something had to be done. GC and ARC modernise the language, but the devil is in the details. For seasoned Cocoa devs, the change is probably relatively moot, but for those coming from other languages, it's a must. --Graham P.S. personally, I still tend to go with MM because the vast majority of the code I work with long predates either GC or ARC. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). It’s fair to say that large chunks of this code could be optimised by removing a bunch of object allocation/deallocation, but I think it’s fairly representative of the style most obj-c code will be written in, and hence a pretty fair test. 100 % slowdown! i suggest you push the Continue button after hitting your breakpoint :) Joking apart, i am surprised that you find things slower, but i never did any adequate performance comparisons myself. Yes, I too was surprised by that, this was in fact the first example I tried profiling, so I was even more surprised, and went out and tested a bunch more bits of code. I don't know what it is like to convert an old project, but I would recommend ARC for new projects and I believe the time investment is worthwhile. For me the distinction is more along performance lines. If you’re dealing with code that you’re already thinking “hmm, rewriting the cores of this in C, rather than high level obj-c would get me a nice performance gain”, then ARC is probably not for that code. If on the other hand, you’re writing an application that does normal interactions with the user, that’s presenting bits of UI, and grabbing data from the internet, and not really doing much CPU intensive stuff, then ARC is almost certainly a major boon for that code. Tom Davie ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Le 9 sept. 2013 à 11:33, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). I'd be interested to dig a little further in what cause the slowdown. Do you have some sample code/file that can be used to stress the library and profile it ? -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 9 Sep 2013, at 11:49, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 11:33, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). I'd be interested to dig a little further in what cause the slowdown. Do you have some sample code/file that can be used to stress the library and profile it ? Sure, there’s a simple example at https://github.com/beelsebob/ParseTest/, alternatively, you can profile the test cases included with CoreParse. Tom Davie ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 9, 2013, at 1:43 AM, Patrick Cusack wrote: Apologies. I have no desire to start an internecine war. I have been reading up on ARC for the past few hours. I also watched the WWDC video on ARC, and after having watched and read everything, I kept feeling as if I was rather comfortable with the old manual memory model. I guess my real question is Why did Apple decide to introduce ARC at all?. I am not convinced that the conventions are any easier than the previous model of manual retain counts. In a large part, it's one less thing to worry about. One less thing to have to keep in your head. Patrick ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 9 Sep 2013, at 10:33, Tom Davie tom.da...@gmail.com wrote: Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). One of the things that has changed in the code that I write, is that in manual retain/release I would often use the autorelease class methods for creating an object arrayWith... etc. and think about the placement of autorelease pools. Using ARC I almost never use these class methods for creating an object but instead use alloc init. I don't have a lot of temporary objects hanging around now. My new project is still so far from ready that optimizing at this point is not sensible. I do have however a bunch of utility functions that do a lot and currently use cocoa for doing the work but that nearly all the cocoa can be replaced by their toll free bridged core foundation equivalents. So if measurement proves that a lot of time is spent in these methods I'll rewrite them then. Kevin ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 9, 2013, at 11:33 , Tom Davie tom.da...@gmail.com wrote: On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: And does the profiler explicitly shows that ARC runtime code is the culprit ? Yes, it does. Isn’t it strange how when someone says “oh, and ARC is faster”, without measurements, that passes without comment? [] The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). It shouldn’t really be surprising. ARC adds an astounding number of additional reference counting ops to all code involving object pointers. If that were compiled, ObjC would be completely unusable and slower than all the so-called scripting languages out there. So for things to be usable, ARC then has the optimizer try to undo most of the damage and finally adds some clever runtime hacks to mitigate the rest. Since the hacks and the remaining damage are somewhat orthogonal, you sometimes end up ahead and sometimes you end up behind. The other thing that should be considered when seeing heroic hacks like the autorelease-undoer is that such techniques rarely arise spontaneously from an idle moment of relaxed performance optimization. More usually, they happen because there is some sort of “ho lee f*k” moment, where performance regression is so bad/project-threatening that something drastic/heroic needs to be done. Corporations and people being what they are, official communication tends to focus more on the heroics than the “ho lee f*k”, so documentation on the performance of new technology tends to be, er, “optimistic”. GC was a classic example of this: yes, there were a few edge cases that you could present where there was a speedup, but overall the performance picture was pretty dismal. Guess what got communicated? I just saw the same thing with dispatch_io, which was presented as a nice performance win in the WWDC talk 2011 (fortunately with the caveat that this was a specific case). Of course, my measurements show it to be a (small) performance loss in most other cases... I don’t even think there’s anything nefarious going on here, just people reporting on a nice win in a specific case with their shiny new toy, and not really that eager to talk about the not-so-good cases. It is probably a good idea to keep that mechanism in mind while gulping down the Cool Aid :-) Cheers, Marcel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
When performance testing ARC code, remember to test in a release configuration, with compiler optimisations on. In my experience, it can really make a big difference; a lot of 'spurious' retain/release pairs are optimised away, and many objects are released earlier. Jamie. On 9 Sep 2013, at 11:15, Kevin Meaney k...@yvs.eu.com wrote: On 9 Sep 2013, at 10:33, Tom Davie tom.da...@gmail.com wrote: Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). One of the things that has changed in the code that I write, is that in manual retain/release I would often use the autorelease class methods for creating an object arrayWith... etc. and think about the placement of autorelease pools. Using ARC I almost never use these class methods for creating an object but instead use alloc init. I don't have a lot of temporary objects hanging around now. My new project is still so far from ready that optimizing at this point is not sensible. I do have however a bunch of utility functions that do a lot and currently use cocoa for doing the work but that nearly all the cocoa can be replaced by their toll free bridged core foundation equivalents. So if measurement proves that a lot of time is spent in these methods I'll rewrite them then. Kevin ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Le 9 sept. 2013 à 11:54, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 11:49, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 11:33, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). I'd be interested to dig a little further in what cause the slowdown. Do you have some sample code/file that can be used to stress the library and profile it ? Sure, there’s a simple example at https://github.com/beelsebob/ParseTest/, alternatively, you can profile the test cases included with CoreParse. Interesting. Actually, after doing a naive ARC migration I find a 30%slow-down on this sample. It look like the main slowdown is induced by an increase of retain/release calls introduced by extra-safety. Each time you send a message to an object, the compiler assumes the object may be released by the message, and so if you need to use this same object again after the message, the compiler make sure it was not released by including a retain/release. For instance, CPItem isEqual: method implemented like this: [object isItem] (object-xxx == xxx) ends up generating something like this: object_retain(object); [object isItem] (object-xxx == xxx) object_release(object), And such method are in hot path (as they are used for hash collection lookup). Unfortunately, I don't know how to tell the compiler to avoid this useless safety. -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 9, 2013, at 3:58 AM, Tom Davie wrote: On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. I think the big point is that if the compiler can figure out what is no longer needed and can be released, and the compiler can do this (at a reasonable cost to performance), then this is a no brainer. I'm sure there are special cases where you would want to do your own memory management. And in this case, you can always flag the class files to turn off ARC and manage memory yourself. Simply put, not having to worry about this gives more brain stack space to fill up with all the other parts of Cocoa and Objective-C that we need to keep track of and saves valuable developer time since it's now rare to have to deal with manual memory management mistakes. Cheers, - Alex Zavatone ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
I appreciate everyone's replies. It was a question asked in complete humility. I agree that computers can do analysis much better than humans and that the less code you write, the less you have to debug, so ARC makes a lot of sense. My question really stemmed from Apple's WWDC lecture which appeared to justify the switch on the flimsiest of grounds, ie no longer having to be confused by [NSString stringWithFormat:] vs [NSString initWithString:] which is a pretty easy memory management rule. As my main application is 32 bit (on account of the Quicktime API), I haven't had much exposure to ARC yet. So I will be upgrading with Mavericks to ARC and AVFoundation. Thanks for all of the comments. Patrick On Sep 9, 2013, at 7:29 AM, Alex Zavatone wrote: On Sep 9, 2013, at 3:58 AM, Tom Davie wrote: On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. I think the big point is that if the compiler can figure out what is no longer needed and can be released, and the compiler can do this (at a reasonable cost to performance), then this is a no brainer. I'm sure there are special cases where you would want to do your own memory management. And in this case, you can always flag the class files to turn off ARC and manage memory yourself. Simply put, not having to worry about this gives more brain stack space to fill up with all the other parts of Cocoa and Objective-C that we need to keep track of and saves valuable developer time since it's now rare to have to deal with manual memory management mistakes. Cheers, - Alex Zavatone ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 9, 2013, at 3:45 PM, Patrick Cusack livinginlosange...@mac.com wrote: I appreciate everyone's replies. It was a question asked in complete humility. I agree that computers can do analysis much better than humans and that the less code you write, the less you have to debug, so ARC makes a lot of sense. My question really stemmed from Apple's WWDC lecture which appeared to justify the switch on the flimsiest of grounds, ie no longer having to be confused by [NSString stringWithFormat:] vs [NSString initWithString:] which is a pretty easy memory management rule. That's not the only motivation, but it's an easy one to illustrate on a slide. It may be a simple rule, but the static analyzer taught us that everybody gets it wrong at least sometimes. Fortunately, the static analyzer also taught us that the Cocoa memory management rules were followed strictly enough in practice to allow them to be automated with only a handful of special cases. Thus, ARC. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
ARC vs Manual Reference Counting
Would anyone agree me that ARC introduces more rules and considerations than
previously existed with manual reference counting?
On Sep 8, 2013, at 12:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
Send Cocoa-dev mailing list submissions to
cocoa-dev@lists.apple.com
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.apple.com/mailman/listinfo/cocoa-dev
or, via email, send a message with subject or body 'help' to
cocoa-dev-requ...@lists.apple.com
You can reach the person managing the list at
cocoa-dev-ow...@lists.apple.com
When replying, please edit your Subject line so it is more specific
than Re: Contents of Cocoa-dev digest...
Today's Topics:
1. Evil setFrame: (Gerriet M. Denkmann)
2. Re: Evil setFrame: (Kyle Sluder)
--
Message: 1
Date: Sun, 08 Sep 2013 11:36:08 +0700
From: Gerriet M. Denkmann gerr...@mdenkmann.de
To: cocoa-dev@lists.apple.com
Subject: Evil setFrame:
Message-ID: 93387169-15d1-42a9-a1c0-fc516ffeb...@mdenkmann.de
Content-Type: text/plain; charset=utf-8
I try to show a nib (which uses autolayout and which contains among other
things a NewView inside an NSClipView inside an NSScrollView ) like this:
if ( self.neuWindowController == nil )
{
// NewWindowController is subclass of NSWindowController
self.neuWindowController = [ [NewWindowController alloc]
initWithWindowNibName: @SomeNib
eventsList:
someArray
];
};
[ self.neuWindowController showWindow: nil ];
The last line triggers in my NewView:
-[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 bounds {{0, 0},
{437, 252}}
-[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 frame {{0, 0},
{437, 252}}
-[NewView resizeWithOldSuperviewSize:] NSClipView 0x10197b8e0 bounds {{0, 0},
{398, 94}}
-[NewView resizeWithOldSuperviewSize:] will call super with oldBoundsSize
{437, 254}
-[NewView setFrame:] will {{0, 0}, {0, 0}} ← why is super doing
this to me ??
-[NewView resizeWithOldSuperviewSize:] got frame {{0, 0}, {0, 0}}
and from here on nothing works (not too surprising with such a small frame).
Something must be terrible wrong in my setup of NewView, but what?
Gerriet.
--
Message: 2
Date: Sat, 07 Sep 2013 22:04:31 -0700
From: Kyle Sluder k...@ksluder.com
To: Gerriet M. Denkmann gerr...@mdenkmann.de,
cocoa-dev@lists.apple.com
Subject: Re: Evil setFrame:
Message-ID:
1378616671.3574.19245285.59d48...@webmail.messagingengine.com
Content-Type: text/plain; charset=utf-8
On Sat, Sep 7, 2013, at 09:36 PM, Gerriet M. Denkmann wrote:
I try to show a nib (which uses autolayout and which contains among other
things a NewView inside an NSClipView inside an NSScrollView ) like this:
if ( self.neuWindowController == nil )
{
// NewWindowController is subclass of NSWindowController
self.neuWindowController = [ [NewWindowController alloc]
initWithWindowNibName: @SomeNib
eventsList:
someArray
];
};
[ self.neuWindowController showWindow: nil ];
The last line triggers in my NewView:
-[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 bounds {{0,
0}, {437, 252}}
-[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 frame {{0,
0}, {437, 252}}
-[NewView resizeWithOldSuperviewSize:] NSClipView 0x10197b8e0 bounds {{0,
0}, {398, 94}}
-[NewView resizeWithOldSuperviewSize:] will call super with oldBoundsSize
{437, 254}
-[NewView setFrame:] will {{0, 0}, {0, 0}} ← why is super doing
this to me ??
-[NewView resizeWithOldSuperviewSize:] got frame {{0, 0}, {0, 0}}
and from here on nothing works (not too surprising with such a small
frame).
Something must be terrible wrong in my setup of NewView, but what?
NewView lacks sufficient constraints to specify its size or position, to
it is being resized to zero.
I'm guessing NewView is the direct subview of the clip view? If so, you
_MUST NOT_ change its translatesAutoresizingMaskIntoConstraints
property, and you _MUST NOT_ try to control its size or position with
constraints.
I learned that the hard way over the course of several months. It's
quite a pain in the ass, because a lot of constraints you'll naturally
want to draw will be just as likely to affect the size of the scroll
view's documentView as they are to use the size of the documentView to
affect the subviews.
In our case, we
Re: ARC vs Manual Reference Counting
Converting to ARC in some ways - depends. On the whole we’re finding positives with it. Writing new apps with it its superb. On September 8, 2013 at 10:44:41 PM, livinginlosange...@mac.com (livinginlosange...@mac.com) wrote: Would anyone agree me that ARC introduces more rules and considerations than previously existed with manual reference counting? Alex Kac - President and Founder Web Information Solutions, Inc.___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Yes. I do. Absolutely. Sent from my iPad On Sep 8, 2013, at 9:41 PM, livinginlosange...@mac.com wrote: Would anyone agree me that ARC introduces more rules and considerations than previously existed with manual reference counting? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Apologies. I have no desire to start an internecine war. I have been reading up on ARC for the past few hours. I also watched the WWDC video on ARC, and after having watched and read everything, I kept feeling as if I was rather comfortable with the old manual memory model. I guess my real question is Why did Apple decide to introduce ARC at all?. I am not convinced that the conventions are any easier than the previous model of manual retain counts. Patrick On Sep 8, 2013, at 10:11 PM, Fritz Anderson wrote: On Sun, Sep 8, 2013 at 11:41 PM, livinginlosange...@mac.com wrote: Would anyone agree [with] me that ARC introduces more rules and considerations than previously existed with manual reference counting? It's not clear which of the two messages, from the entire daily digest you quoted, you are replying to. If you are asking for help of some kind, you might tell us what you need help with, and how the documentation from Apple and clang.llvm.org have let you down. If you have an observation to make, you should make it, rather than task others to make theirs with no clue as to what you are driving at. What rules and considerations are you talking about? It would help us, to know if you've already pondered the thousands of words already published about the rationale for introducing ARC, and the corner cases that remain; and, having pondered them, what fresh rules and considerations you have discovered, or how they might be more-clearly explained. Because you're not just inviting us to another religious war about issues that were resolved (well or badly) years ago, are you? Your phrasing is awfully close to Let's you and him fight. — F ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 8, 2013, at 10:43 PM, Patrick Cusack livinginlosange...@mac.com wrote: Apologies. I have no desire to start an internecine war. I have been reading up on ARC for the past few hours. I also watched the WWDC video on ARC As with anything complex, it’ll take more than a few hours of reading/watching to get comfortable with it. , and after having watched and read everything, I kept feeling as if I was rather comfortable with the old manual memory model. Sure … so was I. But the switch was well worth it. I guess my real question is Why did Apple decide to introduce ARC at all?. I am not convinced that the conventions are any easier than the previous model of manual retain counts. They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
