Das @inlinable Attribut weist den Swift Compiler an, die Implementierung einer Funktion in die Modul-Schnittstellendatei zu serialisieren, sodass der Körper zur Compile-Zeit direkt in die Client-Module kopiert werden kann, um aggressive Optimierungen wie generische Spezialisierung und Konstantenfaltung zu ermöglichen. Da inlined Code jedoch alle Symbolreferenzen innerhalb der Kompilierungseinheit des Clients auflösen muss, müssen alle internal Typen, Funktionen oder Eigenschaften, auf die die @inlinable Funktion zugreift, mit @usableFromInline gekennzeichnet sein, was sie dem Compiler zugänglich macht, ohne sie als öffentliche API zu veröffentlichen.
// Innerhalb eines resistenten Framework-Moduls @usableFromInline internal struct InternalBuffer { @usableFromInline var storage: [Int] } @inlinable public func fastSum(_ buffer: InternalBuffer) -> Int { // Kann auf den internen Speicher aufgrund von @usableFromInline zugreifen return buffer.storage.reduce(0, +) }
Diese Kombination ermöglicht es Bibliotheksautoren, kostenfreie Abstraktionen anzubieten, bei denen generischer Code im Client-Binärformat monomorphisiert wird, obwohl dies einige ABI-Flexibilität opfert, da der Funktionskörper Teil der stabilen binären Schnittstelle wird.
Ein Team, das ein Hochdurchsatz-Maschinelles Lernen-Framework entwickelt, musste eine generische Matrizenmultiplikationsfunktion matmul<T: Numeric> für Client-Anwendungen verfügbar machen, stellte jedoch fest, dass die Überkopfkosten von Funktionsaufrufen über Module hinweg und der Mangel an Spezialisierung die Leistung im Vergleich zu handgeschriebenen Schleifen um vierzig Prozent verringerten. Die Bibliothek wurde als binäres Swift-Paket verteilt, sodass Quellcode-Optimierungen den Clients nicht zur Verfügung standen.
Ein Ansatz bestand darin, alle Hilfstypen und die Implementierungsfunktion public zu machen, wodurch jedes Detail der internen Puffermanagement- und Schrittberechnungen offengelegt wurde. Zwar hätte dies das Inlining ermöglicht, aber es hätte das Team gezwungen, diese spezifischen internen Typen als stabile API für immer zu pflegen, zukünftigen Refaktorisierungen im Wege gestanden und die öffentliche Schnittstelle mit Implementierungsdetails überladen, die Verbraucher niemals direkt anfassen sollten.
Eine andere Option, die in Betracht gezogen wurde, war die Verwendung von @inline(__always), die den Code innerhalb des gleichen Moduls aggressiv inlinet, jedoch den Funktionskörper nicht in andere Module exportiert; das hätte die API sauber gehalten, aber nicht erlaubt, dass der Client-Compiler den generischen T für spezifische numerische Typen wie Float16 oder Double spezialisiert, wodurch die Überkopfkosten für die Laufzeit-Dispatch erhalten blieben und die Leistungsziele verfehlt wurden.
Die Ingenieure markierten letztendlich den Einstiegspunkt mit @inlinable und annotierten die internen Pufferdatenstrukturen und arithmetischen Hilfsfunktionen mit @usableFromInline. Diese Strategie sicherte genügend Implementierungsdetails für den Compiler, um eine vollständige Monomorphisierung und Inlining an den Client-Aufrufstellen zu ermöglichen, während die Symbole aus der öffentlichen Dokumentation herausgehalten wurden. Das Ergebnis war, dass Client-Anwendungen eine Leistung erreichten, die der manuell entworfenen C-Codes entsprach, obwohl die binäre Größe des Frameworks aufgrund der Code-Duplikation zwischen den Modulen leicht anstieg, und das Team akzeptierte, dass das Patchen der Funktion die Clients zur Rekompilierung zwingen würde.
Was ist der grundlegende Unterschied zwischen @inlinable und @inline(__always) hinsichtlich der Modulgrenzen?
@inlinable ist ein Modul-Schnittstellenvertrag, der den Funktionskörper in die .swiftinterface-Datei schreibt und dem Compiler erlaubt, die Implementierung direkt in abhängige Module während ihrer Kompilierung auszugeben, was für die generische Spezialisierung über Module hinweg entscheidend ist. Im Gegensatz dazu ist @inline(__always) lediglich ein Optimierungshinweis für die lokale Kompilierungseinheit; es weist den Optimierer an, den Aufrufstapel innerhalb des Moduls abzuflachen, macht aber den Körper für externe Compiler nicht verfügbar, was bedeutet, dass Client-Module die Funktion weiterhin über resiliente Indirektion aufrufen und die generischen Dispatchkosten nicht beseitigen können.
Warum erfordert Swift @usableFromInline für interne Symbole, auf die von @inlinable Funktionen verwiesen wird, anstatt einfach die Sichtbarkeit abzuleiten?
Wenn eine Funktion in ein Client-Modul inlinet wird, muss der Compiler konkrete Maschinenanweisungen für diesen Code am Aufrufort generieren, was vollständige Typmetadaten und Symboladressen für jede referenzierte Entität erfordert; interne Symbole sind absichtlich von der Modulschnittstelle ausgeschlossen, um die Kapselung durchzusetzen. @usableFromInline fungiert als spezielle Sichtbarkeitsebene nur für Compiler, die die Definition des Symbols in der Schnittstellendatei offenlegt, ohne sie für den clientseitigen Quellcode zugänglich zu machen, wodurch die Anforderungen an die Codegenerierung erfüllt werden, während die Quellcode-Ebene privat bleibt und unerwünschten API-Austritt verhindert wird.
Wie wirkt sich die Annahme von @inlinable auf die ABI-Stabilität und die Eigenschaften der binären Größe einer Swift-Bibliothek aus?
Das Markieren einer Funktion mit @inlinable bettet die Implementierung in die ABI der Bibliothek ein, was bedeutet, dass jede Änderung des Funktionskörpers – beispielsweise das Beheben eines Fehlers oder das Verbessern eines Algorithmus – eine brechende binäre Änderung darstellt, die erfordert, dass alle Client-Module rekompiliert werden, um die Aktualisierung zu sehen, im Gegensatz zu resistenten Funktionen, bei denen die Implementierung unabhängig ausgetauscht werden kann. Darüber hinaus, da der Compiler den Funktionskörper an jedem Aufrufort in allen Client-Binärformaten dupliziert, anstatt auf eine einzelne gemeinsame Bibliotheksadresse zu verweisen, erhöht @inlinable die gesamte binäre Größe der finalen Anwendung erheblich, was es unangemessen für große, selten aufgerufene Hilfsfunktionen macht.