> On Oct 4, 2017, at 9:24 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> - It increases binary size for a function that's rarely used, and which is >> often much larger as an outlined generic function than the simple operation >> that can be inlined into client code. Inlining makes the most sense when the >> inlined operation is smaller than a function call, so in many cases the net >> dylib + executable size would increase. > > I can see this argument, but you’re basically saying that a sufficiently > smart programmer can optimize code size based on (near) perfect knowledge of > the symbol and all clients. I don’t think this is realistic for a number of > reasons. In general, an API vendor has no way to know: > > 1) how many clients it will have, potentially in multiple modules that get > linked into a single app. > 2) on which types a generic function will be used with. > 3) what the code size tradeoffs ARE, e.g. if you have a large function that > doesn’t use the archetype much, there is low bloat. > > Furthermore, we have evidence from the C++ community that people are very > eager to mark lots of things inlinable regardless of the cost of doing so. > Swift may end up being different, but programmers still have no general way > to reason about code size given their declaration and without perfect > knowledge of the clients. > > The code of the approach I’m advocating is one *single* implementation gets > generated in the module that defines the decl. This can lead the N > instantiations of exactly the same unspecialized code (consider the currying > and other cases) in N different modules that end up in an app. This seems > like the right tradeoff.
Also, not all inlinable functions are generic. There are perfectly rationale reasons to inline non-generic functions as well, and they don’t benefit from the specialization benefits you’re indicating. Finally, even if a symbol is generic, it isn’t certain that the client will be able to specialize. The calls may be from unspecialized code after all. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
