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 <[email protected]>
wrote:
>
> On May 6, 2017, at 10:39 PM, Brent Royal-Gordon <[email protected]>
> wrote:
>
> On May 6, 2017, at 10:34 PM, Daniel Dunbar via swift-users <
> [email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
