> On Nov 10, 2017, at 3:05 PM, Joe Groff <jgr...@apple.com> wrote: > > > >> On Nov 8, 2017, at 9:59 PM, Erik Eckstein via swift-dev >> <swift-dev@swift.org> wrote: >> >> >> >>> On Nov 8, 2017, at 5:27 PM, Johannes Weiß via swift-dev >>> <swift-dev@swift.org> wrote: >>> >>> Hi Daniel, >>> >>>> On 2 Nov 2017, at 8:15 pm, Daniel Dunbar <daniel_dun...@apple.com> wrote: >>>> >>>> My personal preference is to: >>>> 1. Do nothing for now, but encourage publishing standardized protocols to >>>> solve this need. >>>> 2. Hope for a future with WMO+LTO magic which recovers the performance, >>>> for the case where the entire application ends up using one implementation. >>> >>> Hmm, but that'll only work if we get 'whole product optimisation', right? >> >> yes. >> >> Even when we have cross-module optimizations (which would be comparable to >> thin-lto) we could not do that optimization. >> >>> If we still compile one module at the time I don't think the compiler will >>> be able to figure out that there's just one implementation of that protocol >>> in the whole program. >> >> exactly > > If you know you're building for an executable target, then it should be > theoretically possible to look at the whole system and see that there's a > single conformance to a protocol. For the situation Johannes is talking > about, maybe this could be information that the build system feeds the > compiler, so in a configuration file somewhere you'd say "I want to > specialize all uses of the Logger.Logger protocol for the > FancyLogger.FancyLogger<MyOutputStream> implementation" instead of relying on > the compiler magically deriving it.
Actually, speculative-devirtualization of protocol methods + cross-module optimization should be able to handle this. The only drawback is code size, which is fortunately not so important for that project. > > -Joe
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
