<div dir="ltr">Is there any chance that the forthcoming memory annotations could help here? If we had some way to signify that the item returned from each call to the closure should be connected to the incoming argument…</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 21, 2017 at 2:27 AM, Charles Srstka via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><blockquote type="cite">On Jan 21, 2017, at 12:37 AM, Russ Bishop <<a href="mailto:xenadu@gmail.com" target="_blank">xenadu@gmail.com</a>> wrote:<br></blockquote><div><blockquote type="cite"><br class="m_-2625158967712448737Apple-interchange-newline"><div><div style="word-wrap:break-word"><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div></blockquote></div><div><blockquote type="cite"><b>I don’t even know how long it actually takes to finish this test, because the last time I did this I eventually got sick of waiting and killed the process. So, I don’t know quite how many orders of magnitude slower it is, but it’s a lot.</b></blockquote><br></div><div>That’s all the endorsement I need. +1 from me.</div><div><br></div><div><br></div><div>I do wonder if there is any way to get this sort of optimization out of the compiler. I suppose it would be difficult because the compiler doesn’t know what the mutable vs immutable pairs are or if such a pair even exists (array doesn’t have appending()).</div></div></div></blockquote></div><br></span><div>The (somewhat naïve) assumption that some optimization of this sort might be going on is what led me to do the speed test in the first place. However, when you think about it, it’d be really quite hard to do. A reduce that builds an array consists of the closure that adds something to an array, and the reduce function itself. With the code to both of these, it’s not inconceivable that the compiler could figure out what you’re doing, but unfortunately the two components live in different modules / compilation units. The closure doesn’t know that its return value is just going to be replacing the passed-in value, and the reduce function doesn’t know that the closure isn’t going to store the original array somewhere, so neither can really know that it’s safe to modify the array in place.</div><div><br></div><div>Charles</div><div><br></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>