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.
On Sun, May 7, 2017 at 11:57 AM, Zhao Xin <owe...@gmail.com> wrote:
> 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?
>
> 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.
>
> Zhaoxin
>
>
>
> On Mon, May 8, 2017 at 12:21 AM, Kelvin Ma via swift-users <
> swift-users@swift.org> wrote:
>
>> 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
>>
>> func f(x:Double, y:Double) -> Double
>> {
>> ....
>> }
>>
>> let z:Double = f(x: point.x, y: point.y)
>>
>> instead, and it seems like something the compiler ought to be responsible
>> for.
>>
>> 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.
>>
>> On Sun, May 7, 2017 at 12:43 AM, Daniel Dunbar <daniel_dun...@apple.com>
>> wrote:
>>
>>>
>>> On May 6, 2017, at 10:39 PM, Brent Royal-Gordon <br...@architechies.com>
>>> wrote:
>>>
>>> On May 6, 2017, at 10:34 PM, Daniel Dunbar via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>> 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
>>>
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> HTH,
>>> - Daniel
>>>
>>>
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>>
>>>
>>>
>>
>> _______________________________________________
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
