(FYI I am already writing a longer response, but got interrupted by visiting with my mother ; )). Give me a bit.
> On Dec 29, 2017, at 2:03 PM, Robert Widmann <devteam.cod...@gmail.com> wrote: > > Ran into this over the summer. My understanding is that Michael Gottesman > (CC’d) has been looking into pattern matching at +0. > > The code in SILGenPattern needs to be reworked, but I found this problem > intersects with the really old dynamic casting entry points in SILGen too > which would seem to complicate a “simple fix”. It’d be good to hear what > plans, if any, there are to address this. It would be a real win to clean all > of this up. > > ~Robert Widmann > > 2017/12/28 14:27、Chris Lattner via swift-dev <swift-dev@swift.org>のメール: > >> <moving to swift-dev, where most of the perf optimization people lurk> >> >> This is a great question, I’m not sure what the answer is: maybe it is a >> simple case missed by the arc optimizer? >> >> -Chris >> >> >> >>> On Dec 27, 2017, at 9:19 PM, Félix Cloutier via swift-evolution >>> <swift-evolut...@swift.org> wrote: >>> >>> Running this on my MBP with 10 as the parameter: >>> https://gist.github.com/zneak/ae33bb970a08632cfb2925e2049f9e7a >>> >>> I get a runtime of about 10 seconds, 45% of which is spent in >>> retain/release calls according to Instruments (!!), and at least half of >>> that from Expr.count. Looking at the IR, Swift generously sprinkles >>> retain/release calls through the outlined copy method: >>> >>> • `self` is retained at the beginning of `count` >>> • The values that you get out of destructuring are retained >>> • Of course, when you get `count` on these, they are retained >>> again >>> >>> Of course, Expr.count cannot modify itself or its subexpressions because >>> the functions are not mutating; in fact, no function in that program can >>> mutate an enum case. Why, then, is Swift retaining/releasing `self` and the >>> values obtained from destructured patterns? They can't go away. Shouldn't >>> we be getting guaranteed references instead of owning references? >>> >>> That seems to hit pattern-matching-heavy programs with indirect cases >>> pretty hard, and it's pretty frustrating because that seems to be about the >>> nicest way to write this program, and there's no workaround from the >>> developer's perspective. I don't think that this is a fatal flaw of >>> refcounting, but unless I'm missing something, that's sub-par behavior. >>> >>> Félix >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolut...@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-dev _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
