<div dir="ltr">copy on write is not intrinsic to structs, is it? I believe copy on write is implemented in Array because Array contains a class for its storage, which checks its own reference count when it is mutated, and String gets the same behavior because String uses an Array as its underlying storage.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 7, 2017 at 11:57 AM, Zhao Xin <span dir="ltr"><<a href="mailto:owenzx@gmail.com" target="_blank">owenzx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">I don't tend to think all of this unless there has been already a noticeable speed drop. So my question is, is there a noticeable drop for you?</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">For your question, in my knowledge, if your function only uses/reads the struct's value, there is no copy in memory. It is called copy on write. The copy won't happen until you write to the copy (mutate the struct's properties). So if your function never mutates the struct, the speed should be very alike as you are using classes.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Zhaoxin</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, May 8, 2017 at 12:21 AM, Kelvin Ma via swift-users <span dir="ltr"><<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><span style="font-family:monospace,monospace">So if I am passing the large struct to a large function, or a function that lives in a different module (as my project is currently split into 8 or 9 modules — is that too many?), am I better off passing the members individually instead of passing the entire struct? It seems kind of tedious to have to write <br><br>func f(x:Double, y:Double) -> Double <br>{<br> ....<br>}<br><br>let z:Double = f(x: point.x, y: point.y) <br><br>instead, and it seems like something the compiler ought to be responsible for.<br><br></span></div><span style="font-family:monospace,monospace">Also about boxing the struct, isn’t that the worst of both worlds? You get the overhead of pass-by-value, the overhead of reference counting, the heap allocation, and the heap access. Plus it’s a lot of work to manually implement copy on write, and the copy is decided at runtime, even when it is known that an object will or won’t be mutated at compile time. <br></span><div><div class="m_-649574576292026175h5"><div><div class="gmail_extra"><span style="font-family:monospace,monospace"><br></span><div class="gmail_quote"><span style="font-family:monospace,monospace">On Sun, May 7, 2017 at 12:43 AM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel_dunbar@apple.com" target="_blank">daniel_dunbar@apple.com</a>></span> wrote:<br></span><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 style="font-family:monospace,monospace"><br></span><div><span style="font-family:monospace,monospace"><span><blockquote type="cite"><div>On May 6, 2017, at 10:39 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:</div><br class="m_-649574576292026175m_6185500928646464087m_8110348481390614979Apple-interchange-newline"><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On May 6, 2017, at 10:34 PM, Daniel Dunbar via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:</div><br class="m_-649574576292026175m_6185500928646464087m_8110348481390614979Apple-interchange-newline"><div><span style="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;float:none;display:inline!important">To answer Kelvin's question, yes, the optimizer will be able to see through that code _assuming_ it can see the definition in a way it can optimize</span></div></blockquote></div><div><br></div><div>Kelvin, you should definitely take Daniel's word over mine on whether there's an optimization for this. I believe the rest of my explanation is correct.</div></div></div></blockquote><div><br></div></span></span><span style="font-family:monospace,monospace">Actually I think yours was more accurate... while it is is true the desired optimization will often take effect (given the conditions I describe), your's was correct that this isn't happening because the function signature is taking _fewer_ arguments. Rather, the optimizations works because the compiler will tend to inline that small function and then see it can discard the unnecessary data.</span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">Whether or not this makes it worth boxing your struct to avoid large copies probably depends on how much you need to pass the struct through call sites which would in fact need to copy the full struct, versus inlining down to something smaller.</span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">HTH,</span></div><div><span style="font-family:monospace,monospace"> - Daniel</span></div><span style="font-family:monospace,monospace"><span class="m_-649574576292026175m_6185500928646464087HOEnZb"><font color="#888888"><div><br></div><div><blockquote type="cite"><div><div style="word-wrap:break-word"><br><div>
<span class="m_-649574576292026175m_6185500928646464087m_8110348481390614979Apple-style-span" style="border-collapse:separate;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div><div style="font-size:12px">-- </div><div style="font-size:12px">Brent Royal-Gordon</div><div style="font-size:12px">Architechies</div></div></span>
</div>
<br></div></div></blockquote></div><br></font></span></span></div></blockquote></div><span style="font-family:monospace,monospace"><br></span></div></div></div></div></div>
<br></div></div><span class="">______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-users</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>