In the WWDC video Binary Frameworks in Swift, they discuss extra runtime costs with using a framework, such as figuring the size of enum types at runtime. Do these same costs apply when using a framework wrapping a static library instead of a dynamic one? I built a library as both static and dynamic, and noticed that the .swiftinterface didn't change at all. How do Swift files that depend on this library know if they'll need to add indirection at runtime for the sake of binary compatibility or not?
1 Like
Many costs like that apply specifically to libraries built with library evolution (-enable-library-evolution). Is that applicable in your case?
Yes, it's the case for me.
Although, the talk was discussing "binary stability" a lot, so I wonder if some of these things apply regardless.
This seems like a fairly important issue, and it's difficult for me to see from the assembly and SIL what's going on
Library evolution provides the same stable ABI whether you build as a static library or a dynamic library. If you don't need to provide a stable ABI, you can disable library evolution and distribute your library as a Swift package instead. If you have particular types or functions where the overhead of library evolution support is unacceptable, and you don't need to reserve the flexibility to change the affected declarations, you might also be able to mark those particular types as @frozen and methods as @inlinable to selectively give up evolution flexibility for performance. All of this is independent of whether you build as a static or dynamic library.
2 Likes