Sorunun Tarihi
Swift 5'ten önce standart String tipi, içerik uzunluğuna bakılmaksızın UTF-16 kodlaması ve yığın tahsisi kullanan bir depolama yöntemiyle çalışıyordu. Bu tasarım, büyük miktarlarda küçük tanımlayıcılar (örneğin JSON anahtarları veya XML etiketleri) işleyen uygulamalar için önemli bir yük getirmiştir; burada bellek tahsis maliyeti veri yükünü aşmaktadır. Swift 5'te yerel UTF-8 kodlamasının benimsenmesi, Küçük Dize Optimizasyonu (SSO) uygulamak için gerekli mimari temeli sağladı; bu teknik, kısa metin yüklerini doğrudan dizinin yerleşik depolamasına gömerek yığın döngüsünü ortadan kaldırır.
Problem
Ana zorluk, 16 baytlık String yapısını (64-bit mimarilerde) hem bayt dizisini hem de meta verileri saklarken tür güvenliğini koruyarak maksimum düzeyde kullanmakta yatıyor. Swift, bir yığın tahsisli _StringStorage nesnesine işaretçi ile anlık UTF-8 byte dizisi arasında ayrım yapmak zorundadır; bunu dış bayraklar kullanmadan veya yapı boyutunu artırmadan gerçekleştirmelidir. Bu, bir bit paketi şeması gerektirir; bu şema bir bit saklama kapasitesinden feragat ederek ayrımcı olarak kullanılacak bir bit sağlar ve dize işlemleri (indeksleme gibi) ile kapasite kontrollerinin temel bellek düzenini doğru bir şekilde yorumlayabilmesini sağlarken, çökme yaşanmasını engeller.
Çözüm
Swift, ilk baytın en anlamlı bitini (LSB) ayrımcı olarak kullanır: 1 değeri, geri kalan alana paketlenmiş 15 bayta kadar bir küçük dizeyi gösterirken, 0, normal bir yığın işaretçisini belirtir (her zaman en az 2 bayt hizalanmış olup, LSB'nin 0 olmasını garanti eder). Bu tasarım, çalışma zamanının count veya withUTF8 gibi erişimciler için uygun kod yolunu seçmek üzere basit bir bitmask işlemi gerçekleştirmesine olanak tanır; böylece küçük dizeler için sıfır maliyetli bir soyutlama sağlanır. Optimizasyon, geliştiriciler için tamamen şeffaftır; API değişikliği gerektirmeden yaygın dize iş yüklerinde önemli performans iyileştirmeleri sunar.
// SSO'nun şeffaflığını gösteren örnek let smallString = "Hello" // 5 bayt, yerinde saklanır let largeString = String(repeating: "a", count: 100) // Yığın tahsisli // API farkı yok, ancak performans özellikleri farklı print(smallString.utf8.count) // Küçük dizeler için O(1)
Bir mobil bankacılık uygulaması, işlem geçmişlerini içeren binlerce tüccar adı ve kategori etiketini işleme sırasında kare düşmeleri yaşıyordu. Profil analizi, bellek tahsis yükünün %40'ının bu kısa dizeleri (ortalama 8-12 karakter) yığın destekli Swift String örneklerine ayrıştırmaktan kaynaklandığını ortaya çıkardı; bu sıklıkla ARC tutma/salınım döngüleri ve önbellek kayıplarını tetiklüyordu. Mühendislik ekibi, bu küçük, geçici değerler için tahsis tıkanıklığını ortadan kaldırırken Swift'in dize API'sinin güvenliğini ve ifadeliliğini koruyacak bir çözüm bulmak zorundaydı.
Önerilen bir yaklaşım, tüm ayrıştırılan metinlerin, küçük dizeleri kendisinde depolayan işaretçi optimizasyonlarından yararlanmak için Objective-C NSString nesnelerine köprülenmesini içeriyordu. Bu, NSString için yığın tahsisini ortadan kaldırırken, Swift String'e geri dönüş yaparken yüksek maliyetli kopyala-yaz işlemlerini ve uygulamanın arka plan işleme hattı için gereken Sendable uygunluk garantilerini bozuyordu. Sonuç olarak, ekip bu yaklaşımı kabul edilemez çevresel güvenlik riskleri ve dil sınırını aşmanın maliyeti yüzünden terk etti.
Başka bir mühendis, sabit boyutlu bir bayt tamponunu manuel olarak yönetmek için UnsafeMutablePointer kullanarak String yerine özel bir SmallString yapısı önerdi; teorik olarak bu, bellek düzeni üzerinde tam kontrol sağlıyordu. Bu belirleyici bir yığın tahsisi sağlarken, yeniden Unicode normalizasyonu, grafik kümesi kırılması ve Equatable uygunluğunu sıfırdan yeniden uygulamayı gerektiriyordu; bu, felakete yol açacak bir karmaşıklık ve potansiyel güvenlik açıkları ile sonuçlandı. Bakım yükü ve veri bozulma riski, performans yararlarını geçerek bunun reddedilmesine neden oldu.
Ekip, nihayetinde ayrıştırma mantığını yerel Swift String ve Substring kullanarak yeniden düzenlemeyi seçti. Bölme işlemlerinin dize uzunluklarını 15 baytın üzerine yapay olarak şişirmediğinden emin oldular. Swift 5.0'a geçerek, yerleşik Küçük Dize Optimizasyonu'na güvenerek uygulama otomatik olarak tüccar adlarının %90'ını yerinde sakladı, yığın tahsislerini %85 oranında düşürdü ve kare düşmelerini ortadan kaldırdı. Bu çözüm, yalnızca minimal kod değişiklikleri gerektirdi—özellikle manuel NSString dönüşümlerinin kaldırılması—ve tam tür güvenliğini ve eşzamanlılık uyumluluğunu korudu.
Dağıtım sonrası metrikler, bellek ayak izinde %30 azalma ve liste kaydırma sırasında malloc'ta harcanan CPU zamanında %50 düşüş gösterdi. Geliştirme ekibi, Swift'in şeffaf optimizasyonlarının genellikle manuel mikro optimizasyonlardan daha iyi performans gösterdiğini öğrendi; tabi ki geliştiricilerin arka plandaki kısıtlamaları (örneğin 15 bayt sınırı) anlamaları şartıyla, böylece istemeden birleştirme yoluyla yığın yükselmesini zorlamaktan kaçınılabilirdi.
Çalışma zamanı, bir küçük dize ile bir yığın işaretçisini bit düzeyinde nasıl ayırt eder ve bu spesifik bit neden seçilmiştir?
Çalışma zamanı, dizenin ham yükündeki ilk baytın en anlamlı bitini inceler. Bu bit, küçük dizeler için 1, yığın işaretçileri için ise 0'dır; çünkü Swift'teki tüm yığın tahsisleri en az 2 bayt hizalanmıştır ve bu, adreslerin her zaman 0 ile bitmesini garanti eder. Adaylar sıklıkla yüksek bitin kullanıldığını yanlış bir şekilde öne sürüyor ve LSB seçimlerinin, yüksek bit kaydırma yükü olmadan basit bir & 1 maskesi ile verimli dallanmayı sağlamasını gözden kaçırıyorlar; ayrıca hizalama garantileri, bu ayrımın tartışmasız olmasını sağlıyor.
64-bit platformlarında küçük bir dizenin tam bayt kapasitesi nedir ve UTF-8 kodlaması görünür karakter sayısını nasıl etkiler?
Kapasite, 64-bit mimarilerde tam olarak 15 bayt UTF-8 yüküdür; çünkü bir bayt uzunluk meta verisi ve ayrımcı bit için ayrılmıştır. UTF-8 değişken uzunluklu kodlama (her bir Unicode scalar için 1-4 bayt) kullandığından, küçük bir dize 15 ASCII karakter saklayabilir, ancak yalnızca 3-4 emoji veya karmaşık CJK karakteri saklayabilir. Yeni başlayanlar, sınırın 16 bayt veya 15 karakter olduğunu varsayarak, kısıtlamanın kodlanmış bayt uzunluğuna değil, grafik kümesi sayısına uygulandığını yanlış anlıyorlar.
Küçük bir dize 15 baytı aşacak şekilde değiştirildiğinde, Swift değer anlamsını bozmadan yığın tahsisine geçişi nasıl yönetir?
Bir değişiklik (örneğin append) bayt sayısının 15'i aşmasına neden olduğunda, Swift yığın üzerinde yeni bir _StringStorage tamponu tahsis eder, mevcut 15 baytı ve yeni içeriği kopyalar ve dizenin ayrımcı bitini 0 olarak güncelleyerek yığın işaretçi düzenine geçiş yapar. Bu geçiş, orijinal dizenin değişmeden kalmasını sağladığı için değer anlamsını korur (eşsiz referans kontrolü tarafından tetiklenen kopyala-yaz davranışı sayesinde) ve yeni dize genişletilmiş yığın tamponuna işaret eder. Adaylar sıklıkla, bu "yükseltmenin" tam bir tahsis ve kopya tetiklediğini kaçırıyorlar; bu, 15 bayt eşiği etrafında salınan tekrar eden ekleme işlemlerinin, büyük bir tamponun önceden tahsis edilmesinden daha pahalı olabileceği anlamına geliyor.