Soru tarihçesi.
C++11'den önce birçok std::string uygulaması, kopyaların bellek ayak izini azaltarak dizgilerin veri paylaşımını sağlamak için referans sayımı (Kopya Üzerine Yazma) kullanıyordu. Ancak bu yaklaşım, iç referans sayısı değiştiğinde aynı anda okuma işlemlerinin geçersiz hale gelmesine neden olan, çoklu iş parçacığı güvenliği sorunları yarattı. C++11 bu optimizasyonu açıkça yasakladı ve referansların veya iteratörlerin geçersiz hale gelmeyeceği, const üye fonksiyonlarının gerektirilmesi gerekti; bu, kısa diziler için yığın tahsisatının performans maliyetini azaltmak amacıyla yeni bir optimizasyon stratejisi gerektiriyordu.
Sorun.
Yığın tahsisi, tahsisatçıların senkronizasyon aşırı yükü ve önbellek yerleşim sorunları nedeniyle pahalıdır. JSON ayrıştırıcıları veya ağ protokolü işleyicileri gibi birkaç milyar küçük diziyi işleyen uygulamalar için, 5-15 karakter dizileri için bellek tahsis etmek yürütme süresinin büyük bir bölümünü kaplar. Zorluk, std::string nesnesinin kendisinde küçük dizilerin saklanmasıdır — genellikle 64 bitli sistemlerde 32 bayt ile kısıtlanmış — ABI uyumluluğunu bozmadan veya standartın gerektirdiği güçlü istisna güvenliği garantilerini ihlal etmeden.
Çözüm.
Uygulamalar genellikle depolama tamponu için üç üyeden oluşan bir birlik (union) kullanır: char* ptr_ yığın tahsis edilen dizi için, size_t capacity_ ve gömülü dizi için char local_buffer_[N]. Bir ayırt edici, genellikle size_ üyesinin en az anlamlı bitinde veya belirli bir kapasite değerinde kodlanır, bu, dizinin "SSO modu" veya "yığın modu" içinde olup olmadığını belirler. size() < SSO_CAPACITY olduğunda, karakterler local_buffer_ içinde saklanır, local_buffer_[size()]'de bir null terminatör ile yığın tahsisini tamamen önleyerek. Daha büyük dizilerde, ptr_ yığın belleğe işaret eder ve local_buffer_, kapasite meta verilerini saklamak için yeniden kullanılabilir veya kullanılmaz.
// Kavramsal uygulama (basitleştirilmiş) class string { union { struct { char* ptr; size_t size; size_t cap; } heap; // cap >= SSO_CAP olduğunda etkin struct { char buffer[15]; // 15 karakter + null terminatör unsigned char size; // Paketlenmiş meta veriler, MSB yığını gösteriyor } sso; // size < 15 olduğunda etkin } data; bool is_sso() const { return (data.sso.size & 0x80) == 0; } };
Birçok küçük etiket içeren FIX protokolü mesajlarını işleyen yüksek frekanslı bir ticaret uygulaması düşünün (örneğin, "35=D", "150=2"). İlk uygulama, her etiket değerini saklamak için std::string kullanıyordu ve bunun sonucunda saniyede milyonlarca yığın tahsisi ile ciddi tahsisatçı rekabeti oluştu, bu da piyasa verisi akışını bottleneckteyordu.
Çözüm A: Tampon üzerinde ham işaretçiler. Orijinal mesaj tamponuna char* işaretçileri kullanmak sıfır tahsisat aşırı yükü sunar ve maksimum performans sağlar. Ancak, bu yaklaşım, orijinal tampon yeniden kullanıldığında veya serbest bırakıldığında, string verileri hala gerekli olduğunda, kullanım sonrası serbest bırakma hatalarına neden olabilecek tehlikeli ömür yönetimi sorunları getirir. Ayrıca, dize uzunluklarını manuel olarak takip etmeyi gerektirir, bu da kod karmaşıklığını ve hata potansiyelini artırır.
Çözüm B: Bellek havuzlarıyla özel tahsisatçı. İş parçacığı yerel bellek havuzları uygulamak, tahsisatçı rekabetini azaltarak tahsisatları gruplayarak tahsisatçı rekabetini azaltır. Ancak, bu önemli bir şablon karmaşıklığı ekler veya kod tabanı boyunca polymorfik tahsisatçılar gerektirir. Ayrıca, tahsisat aşırı yükünü tamamen ortadan kaldırmaz, yalnızca maliyeti birden fazla dizi arasında dağıtır.
Çözüm C: std::string_view ve SSO. Okunabilir işleme için std::string_view kullanmak kopyaları önlerken, saklanan değerler için std::string'in otomatik SSO'suna güvenmek, minimum aşırı yükle güvenlik sağlar. Ana dezavantaj, dizilerin SSO eşiklerini (15-22 karakter) aştıklarında, pahalı yığın tahsisatlarını tetikleyen performans uçurumudur. Ayrıca, küçük dizilerin taşınması, veri kopyalamakla sonuçlanır, bu da O(1) taşıma semantiği bekleyen geliştiricileri şaşırtabilir.
Ekip Çözüm C'yi seçti ve ayrıştırıcıyı geçici referanslar için std::string_view kullanacak şekilde yeniden yapılandırdı ve sadece kalıcılık gerektiğinde std::string kullandı. Bu, tipik FIX mesajları için yığın tahsisatlarını %95 oranında azalttı ve bellek güvenliğini koruyarak iletim hızını 50.000'den 800.000 mesaja çıkardı.
SSO'yu kullanan kısa bir dizgenin taşınmasında neden karakter kopyası yapıldığına ve bunun taşınan nesnenin durumunu nasıl etkilediğine dair açıklama yapın.
SSO modunda, karakter dizisi doğrudan std::string nesnesinin içinde yer alır (genellikle bir iç birliğin üyesi olarak). Yığın tahsis edilen dizilerde taşınma iletkeninin sadece char* işaretçisini aktararak ve kaynağı sıfırlayarak yapılan işlemlerin aksine, bir SSO dizisini taşımak, kaynak nesnenin iç tamponundan hedefin iç tamponuna karakterleri kopyalamayı gerektirir. Bunun sebebi, kaynak nesnesinin yok edileceği ve bununla birlikte iç tamponun da yok olacağıdır; bu nedenle, hedef nesne yakında yok olacak kaynak içindeki belleğe işaret edemez. Sonuç olarak, küçük bir diziyi taşımak O(N) karmaşıklığına sahip oluyor, O(1)'den ziyade ve taşınan nesne geçerli ama belirsiz bir durumda (boş değil) kalmaya devam ediyor, hala yok olma veya yeniden atama işlemine kadar orijinal karakterleri içeriyor.
SSO modu çalışırken std::string'in C++11 gereksinimini c_str() ve data()'nın null-terminatörlü karakter dizileri döndürmesini nasıl sağladığını açıklayın; bu, iç tampon boyutunun sabit olmasına rağmen.
Uygulama, SSO tamponunun her zaman maksimum SSO kapasitesinden bir bayt daha büyük (örneğin, 15 karakterli dize için toplam 16 bayt) olmasını sağlar. N uzunluğunda bir dize saklandığında (burada N < SSO_CAPACITY), uygulama N konumunda null terminatörü yerel tampon içine yazar. data() ve c_str() metodları, SSO modundayken bu yerel tamponun başlangıcına işaret eden bir işaretçi döndürür, yığın işaretçisi yerine. Bu şekilde, ek tahsisi olmadan null sonlandırmayı garanti ederek, standartların c_str()'nın null-terminatörlü diziye const char* döndürmesini ve C++11'den bu yana data()'nın da null-terminatörlü diziye işaret etmesini gerektiren gerekliliklerini karşılamış olur.
Boş bir std::string'in capacity()'sinin farklı standart kütüphane uygulamaları arasında neden değişebileceğini (örneğin, 15 vs 22) ve bunun farklı standart kütüphane sürümlerinin karışımına yönelik ABI etkilerini açıklayın.
SSO tampon boyutu bir uygulama detayıdır (libc++ genellikle 64 bitli sistemlerde 22 karakter kullanırken, libstdc++ 15 kullanır). Bu boyut, uygulamanın boyut/kapasite meta verilerini yerel tampon ile birlikte std::string nesnesi yerleşiminde nasıl yerleştirdiğine bağlıdır (genellikle toplam 32 bayt). Bu standartlaştırılmadığı için, farklı standart kütüphane uygulamaları ile derlenmiş karışık ikili dosyalar oluşturmak (örneğin, GCC ile derlenmiş bir kütüphaneden geçen bir std::string ile Clang ile derlenmiş bir uygulama), uyumsuz bellek yerleşimi nedeniyle belirsiz davranışa yol açar. Adaylar, std::string'in standart bir ABI'ye sahip olduğunu varsayıyor, ancak bu, kütüphane sınırları boyunca en az taşınabilir olan türlerden biridir.