<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">My understanding (from what I’ve seen in the literature, but I am in no way an expert) is that RC has worse worse case behaviour than GC regarding pauses.</div><div class=""><br class=""></div><div class="">Also arguments regarding RAM use (and perhaps even battery use), as all hardware resource-based arguments, have always been proven wrong in the past as hardware has evolved to more and better.</div><div class=""><br class=""></div><div class="">The usual argument is RAM is cheap, programmer’s time, especially debugging time, is expensive.</div><div class=""><br class=""></div><div class="">I find it interesting that the commonly accepted wisdom is that GC is the right thing to do. To quote but one blog post I’ve read:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="color: rgb(35, 31, 32); font-family: 'Open Sans', sans-serif; font-size: 13.888888359069824px; background-color: rgb(255, 255, 255);" class="">It’s a long since resolved dispute, and GC won. I don’t want Steve Jobs to reach out from the grave and drag us back to the 70s. There’s nothing special about mobile phones: they are more powerful than the computers that GC won on in the first place.</span></blockquote></div><div class=""><br class=""></div><div class="">So I’d be interested in understanding why we are about alone on our Apple island with our opinion that RC is better than GC? Are they all collectively wrong in the rest of the universe? (not that I condone argument from majority)</div><div class=""><br class=""></div><div class="">I can only state that my experience with GC has been with mostly with Macintosh Common Lisp a rather long time ago, and I did really love it.</div><div class=""><br class=""></div><div class="">So for me, GC would be a +1, but not a very strong one, as I find RC adequate.</div><div class=""><br class=""></div><div class="">Jean-Denis</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 09 Feb 2016, at 07:01, Colin Cornaby via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I thought I’d add my opinion to this thread even though it’s been well covered in different posts, just to put more weight on the -1 argument…<div class=""><br class=""></div><div class="">I spend most my time dealing with performance sensitive code, and Swift’s predictability is a very strong pro for it against languages like Java. Java’s garbage collector provides too much uncertainty and instability to performance.</div><div class=""><br class=""></div><div class="">There certainly are tradeoffs. ARC won’t catch things like circular retain loops. But as mentioned, tagged pointers on the modern architecture take care of the retain/release overhead.</div><div class=""><br class=""></div><div class="">I’ll put it a different way that sums up why I felt the need to reply: ARC has it’s inconveniences, but moving to garbage collection would likely lead us to abandon any plans to adopt Swift for many of our performance sensitive projects. If someone solves the “pausing” problem in a garbage collected language I’d reconsider. But until then it would take Swift out of consideration for a lot of projects.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 8, 2016, at 11:56 AM, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Has there been a garbage collection thread so far? I understand that reference counting vs. garbage collection can be a heated debate, but it might be relevant to have it.</div><div class=""><br class=""></div><div class="">It seems to me that the two principal upsides of reference counting are that destruction is (essentially) deterministic and performance is more easily predicted. However, it comes with many downsides:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">object references are expensive to update</li><li class="">object references cannot be atomically updated</li><li class="">heap fragmentation</li><li class="">the closure capture syntax uses up an unreasonable amount of mindshare just because of [weak self]</li></ul></div><div class=""><div class=""><br class="webkit-block-placeholder"></div><div class="">Since Swift doesn't expose memory management operations outside of `autoreleasepool`, it seems to me that you could just drop in a garbage collector instead of reference counting and it would work (for most purposes).</div><div class=""><br class=""></div><div class="">Has a GC been considered at all?</div><div class="">
<br class="Apple-interchange-newline"><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Félix</span>
</div>
<br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>