Swift verwendet eine Optimierungsstrategie namens Copy-on-Write (COW) für Werttypen, die den Heap-allocierten Speicher umhüllen. Anstatt sofort bei der Zuweisung eine tiefe Kopie durchzuführen, verzögert die Sprache die Duplikation, bis die Instanz tatsächlich geändert wird. Dies wird erreicht, indem der Werttyp intern auf eine gemeinsame unterstützende Klasse verweist und die Laufzeitfunktion isKnownUniquelyReferenced verwendet wird, um festzustellen, wann die Referenzanzahl eins entspricht. Wenn eine Mutation auftritt und die Referenz einzigartig ist, wird der Puffer vor Ort modifiziert; andernfalls wird eine Kopie erstellt, bevor geschrieben wird, wodurch die Wertsemantik ohne die Leistungsnachteile des frühen Kopierens erhalten bleibt.
Unser Team baute eine Hochleistungs-Bildverarbeitungs-Pipeline, in der wir eine benutzerdefinierte Image strukt definierten, die einen großen CVPixelBuffer-Verwaltungsspeicher umwickelte. Das Problem trat während der Profilerstellung auf: Jede Filteranwendung erzeugte drei Zwischenkopien von 4K-Bildern, was pro Frame 300 MB Allokationen verursachte und Speichermeldungen auf iPad-Geräten auslöste.
Wir betrachteten drei unterschiedliche Ansätze, um diesen Engpass zu lösen. Der erste Ansatz bestand darin, Image von einer strukt in eine klasse umzuwandeln. Dadurch wurden Kopien vollständig eliminiert, indem Referenzsemantiken verwendet wurden, aber es traten schwerwiegende Thread-Sicherheitsfehler auf, als mehrere Verarbeitungsstränge versehentlich dieselben Pixel-Daten gleichzeitig teilten und änderten, was zu visuellen Artefakten und Rennbedingungen führte, die schwer zu debuggen waren.
Der zweite Ansatz hielt die strukt-Bezeichnung bei, führte jedoch manuelles tiefes Kopieren mit UnsafeMutablePointer und memcpy-Optimierungen durch. Dies gewährte Sicherheit durch strikte Wertsemantik, aber die Profilerstellung zeigte, dass es 800 % mehr CPU-Zeit als unser Ziel verbrauchte, da jedes Funktionsargument eine 12 MB-Speicherallokation und bitweise Kopieroperation auslöste.
Der dritte Ansatz implementierte Copy-on-Write-Semantik manuell. Wir erstellten eine private ImageBuffer Klasse, um den tatsächlichen CVPixelBuffer zu halten, ließen die Image Struktur auf diese Klasse verweisen und implementierten alle ändernden Methoden, um isKnownUniquelyReferenced vor der Modifizierung zu überprüfen:
final class ImageBuffer { var pixels: CVPixelBuffer init(_ buffer: CVPixelBuffer) { self.pixels = buffer } } struct Image { private var buffer: ImageBuffer mutating func applyFilter(_ filter: Filter) { if !isKnownUniquelyReferenced(&buffer) { buffer = ImageBuffer(buffer.pixels.deepCopy()) } filter.prozess(buffer.pixels) } }
Wenn die Referenz nicht einzigartig war, duplizierten wir zuerst den Puffer. Wir wählten diese Lösung, weil sie die Sicherheit der Wertsemantik von Swift bewahrte, während unnötige Kopien während der schreibgeschützten Operationen vermieden wurden.
Das Ergebnis reduzierte den Speicherbedarf um 94 % und verbesserte die Bildverarbeitungszeit von 120 ms auf 18 ms pro Bild, sodass die App Echtzeit-Videostreams ohne thermische Drosselung auf älterer Hardware verarbeiten konnte.
Warum können wir nicht manuell Referenzzahlen überprüfen, anstatt isKnownUniquelyReferenced zu verwenden?
Viele Kandidaten schlagen vor, die Referenzzahlen manuell zu verfolgen oder Speicheradressen zu vergleichen. isKnownUniquelyReferenced ist jedoch nicht nur eine Zählüberprüfung; sie umfasst vom Compiler eingefügte Barrieren, die verhindern, dass Optimierungen Speicheroperationen neu anordnen. Ohne diese intrinsische Prüfung könnte der Compiler die Überprüfung auf Einzigartigkeit optimieren, oder die Laufzeit könnte aufgrund von Objective-C-Laufzeitinteraktionen oder Brückenumwandlungen, die zusätzliche unbesessene Referenzen aufrechterhalten, die für die standardmäßige ARC-Zählung unsichtbar sind, falsche Positiven zurückgeben.
Wie interagiert COW mit Swifts Exklusivitätsdurchsetzung?
Kandidaten glauben oft, dass COW automatisch für alle Werttypen funktioniert, die Klassen enthalten. Sie übersehen, dass die Exklusivitätsregeln von Swift verlangen, dass Mutationen exklusiven Zugriff haben. Bei der Implementierung von benutzerdefiniertem COW muss die Überprüfung von isKnownUniquelyReferenced erfolgen, bevor die Mutation beginnt, und der Pufferersatz muss atomar in Bezug auf die Überprüfung erfolgen. Das Verletzen dieser Regel, indem mehrere Referenzen während der Überprüfung gehalten werden, kann zur Auslösung von Laufzeiteinträgen der Exklusivität oder zur Verursachung von falschen Negativen in der Einzigartigkeitsüberprüfung führen.
Wann kann COW Kopieren in konkurrierenden Kontexten nicht verhindern?
Mit dem Concurrent-Programmierungsmodell von Swift 5.5 nehmen die Kandidaten an, dass COW eine thread-sichere Mutation bietet. COW gewährleistet jedoch Sicherheit nur innerhalb eines einzelnen Threads. Wenn Werte über Akteurgrenzen hinweg übergeben oder als Sendable gekennzeichnet werden, kann der Compiler eine frühzeitige Kopie erzwingen, um die Isolation zu gewährleisten. Darüber hinaus kann, wenn die unterstützende Klasse Objective-C-Objekte enthält, isKnownUniquelyReferenced aufgrund der schwachen Referenzimplementierung von Objective-C konservativ falsche Ergebnisse liefern, die unnötige Kopien verursachen, die eine Umstrukturierung des Besitzmodells zur Optimierung erfordern.