STL büyük uygulamalarda kullanılmamalıdır?

Bu garip bir soru gibi gelebilir, ancak bölümümde aşağıdaki durumla ilgili sorun yaşıyoruz:

Burada, daha büyük ve daha da büyüyen bir sunucu uygulaması üzerinde çalışıyoruz, hatta farklı parçalara bölmeyi düşündüğümüz noktada (DLL dosyaları), gerektiğinde dinamik olarak yükleme ve daha sonra boşaltma işlemleri yapabilmek için performans sorunları.

Ancak, kullandığımız fonksiyonlar, giriş ve çıkış parametrelerini STL nesneleri olarak geçiyor ve Yığın Taşması cevabında da belirtildiği gibi , bu çok kötü bir fikir. (Yazı bazı ± çözümler ve kesmeler içeriyor, ancak hepsi çok sağlam görünmüyor.)

Açıkçası giriş / çıkış parametrelerini standart C ++ tipleriyle değiştirebilir ve bir kez fonksiyonların içindekilerden STL nesneleri yaratabiliriz, ancak bu performans düşmelerine neden olabilir.

Tek bir bilgisayarın artık kaldıramayacağı kadar büyük bir uygulama geliştirmeyi planlıyorsanız, STL'yi hiç bir teknoloji olarak kullanmamanız gerektiğine karar vermek doğru mudur?

Bu soru hakkında daha fazla bilgi:
Soruyla ilgili bazı yanlış anlamalar var gibi görünüyor: sorun şu:
Uygulamam çalışmasını tamamlamak için büyük miktarda performans (CPU, bellek) kullanıyor ve bu çalışmayı bölmek istiyorum farklı parçalara (program zaten çoklu fonksiyonlara bölündüğü için), uygulamalarımdan bazı DLL'ler oluşturmak ve bu işlevlerin bazılarını bu DLL'lerin dışa aktarma tablosuna koymak zor değildir. Bu, aşağıdaki durumla sonuçlanacaktır:

+-----------+-----------+----
| Machine1  | Machine2  | ...
| App_Inst1 | App_Inst2 | ...
|           |           |    
| DLL1.1    | DLL2.1    | ...
| DLL1.2    | DLL2.2    | ...
| DLL1.x    | DLL2.x    | ...
+-----------+-----------+----

App_Inst1, Machine1'de yüklü olan uygulamanın bir örneğidir; App_Inst2, Machine2'ye yüklenen aynı uygulamanın bir örneğidir.
DLL1.x, Machine1'de yüklü bir DLL iken, DLL2.x, Machine2'de yüklü bir DLL'dir.
DLLx.1 verilen işlevi1 kapsar.
DLLx.2 verilen işlevi2 kapsar.

Şimdi Makine1'de, işlev1 ve işlev2'yi çalıştırmak istiyorum. Bunun Machine1'i aşırı yükleyeceğini biliyorum, bu nedenle App_Inst2'ye bir mesaj göndermek istiyorum, bu uygulama örneğinden function2 işlemini yapmasını istiyorum.

Function1 ve function2'nin girdi / çıktı parametreleri STL (C ++ Standart Tür Kitaplığı) nesneleridir ve müşteriden App_Inst1, App_Inst2, DLLx.y güncellemelerini yapmasını bekleyebilirim (ancak hepsi değil, müşteri Machine1'i yükseltebilir, ancak Machine2 değil, veya yalnızca uygulamaları yükseltin, ancak dll'leri veya tam tersi, ...). Açıkça görüldüğü gibi, arayüz (giriş / çıkış parametreleri) değişirse, müşteri tam yükseltme yapmak zorunda kalır.

Bununla birlikte, belirtilen StackOverflow URL'sinde belirtildiği gibi, App_Inst1 veya DLL'lerden birinin basit bir yeniden derlemesi tüm sistemin parçalanmasına neden olabilir, bu nedenle STL (C ++ Standart Şablonu) kullanılmasını önererek bu yazının orjinal başlığım Kütüphane) büyük uygulamalar için.

Umarım bazı soruları / şüpheleri gidermişimdir.

Bu çok soğuk bir klasik XY problemi.

Sizin asıl sorun performans sorunları olduğunu. Ancak sorunuz, performans sorunlarının gerçekte nereden geldiğine dair hiçbir profil veya başka değerlendirme yapmadığınızı açıkça ortaya koyuyor. Bunun yerine, kodunuzu DLL'lere bölmenin sorunu sihirli bir şekilde çözeceğini umuyorsunuz (ki bu kayıt için olmayacak) ve şimdi bu çözüm dışı durumun bir yönü hakkında endişelisiniz.

Bunun yerine, asıl sorunu çözmeniz gerekir. Birden fazla çalıştırıcınız varsa, hangisinin yavaşlamaya neden olduğunu kontrol edin. Bu işteyken, kötü bir şekilde yapılandırılmış bir Ethernet sürücüsü ya da onun gibi bir şey değil, tüm işlem sürelerini gerçekten de uyguladığınızdan emin olun. Bundan sonra, kodunuzdaki çeşitli görevleri profillemeye başlayın. Yüksek hassasiyetli zamanlayıcı burada senin arkadaşın. Klasik çözüm, bir kod parçası için ortalama ve en kötü durum işleme sürelerini izlemektir.

Verileriniz olduğunda, sorunla nasıl başa çıkabileceğinizi öğrenebilir ve ardından nerede optimize edeceğinizi hesaplayabilirsiniz.

Bir yazılımı birden fazla fiziksel makine arasında bölmek zorunda kalırsanız, veriler arasında makineler arasında veri aktarırken bazı serileştirme formlarına sahip olmanız gerekir, çünkü bazı durumlarda gerçekte makineler arasında aynı ikiliyi gönderebilirsiniz. Serileştirme yöntemlerinin çoğunda STL tipleri ile ilgili herhangi bir problem yoktur, bu yüzden bu durum beni endişelendirecek bir şey değildir.

Bir uygulamayı Paylaşılan Kitaplıklara (DLL) bölmek zorundaysanız (bunu performans nedenleriyle yapmadan önce, gerçekten performans sorunlarını çözeceğinden emin olmalısınız), STL nesnelerini iletmek bir sorun olabilir ama olmak zorunda değildir. Sağladığınız bağlantıda açıklandığı gibi, aynı derleyiciyi ve aynı derleyici ayarlarını kullanıyorsanız STL nesnelerini iletmek işe yarar. Kullanıcılar DLL dosyaları sağlarsa, bu hesaba kolayca güvenemeyebilirsiniz. Ancak tüm DLL'leri sağlar ve her şeyi birlikte derlerseniz, buna güvenebilir ve DLL sınırlarında STL nesnelerini kullanmak çok mümkün olabilir. STL'ye özgü bir sorun olmasa da, derleyici ayarlarına dikkat etmeniz gerekiyor, böylece nesne sahipliğini iletirseniz birden fazla farklı yığın elde edemezsiniz.

Burada, daha büyük ve daha da büyüyen bir sunucu uygulaması üzerinde çalışıyoruz, hatta farklı parçalara bölmeyi düşündüğümüz noktada (DLL), gerektiğinde dinamik olarak yükleme ve daha sonra boşaltma işlemi yapabilmek için performans sorunları

RAM ucuzdur ve bu nedenle aktif olmayan kod ucuzdur. Kod yükleme ve boşaltma (özellikle boşaltma) kırılgan bir işlemdir ve programlarınızın modern masaüstü / sunucu donanımı üzerindeki performansını önemli ölçüde etkilemesi muhtemel değildir.

Önbellek daha pahalıdır, ancak bu kullanılmayan bellekte oturan kodu değil, yalnızca son zamanlarda etkin olan kodu etkiler.

Genel olarak programlar, bilgisayarlarını kod boyutu yerine veri boyutu veya CPU zamanı nedeniyle büyütür. Kod büyüklüğünüz çok büyük sorunlara neden olacak kadar büyüyorsa, muhtemelen ilk başta bunun neden olduğunu görmek istersiniz.

Ancak, kullandığımız fonksiyonlar, giriş ve çıkış parametresini STL nesneleri olarak iletiyor ve bu StackOverflow URL'sinde belirtildiği gibi, bu çok kötü bir fikir.

Görevler ve çalıştırılabilir dosyalar aynı derleyici ile oluşturulduktan ve aynı C ++ çalışma zamanı kitaplığına dinamik olarak bağlandığı sürece sorun çözülmemelidir. Uygulama ve bununla ilişkili görevlerin tek bir ünite olarak oluşturulması ve konuşlandırılması durumunda sorun yaşanmaması gerektiği izlenir.

Problem olabileceği yer, kütüphanelerin farklı kişiler tarafından inşa edildiği veya ayrı olarak güncellenebildiği zamandır.

Tek bir bilgisayarla artık başa çıkamayacak kadar büyük olabilecek bir uygulama oluşturmayı düşünüyorsanız, STL'yi hiç bir teknoloji olarak kullanmamanız gerektiği sonucuna varılabilir mi?

Pek sayılmaz.

Bir uygulamayı birden fazla makineye yaymaya başladığınızda, verileri bu makineler arasında nasıl aktardığınızla ilgili tüm düşünceleriniz vardır. STL tipleri veya daha fazla temel tiplerin kullanılıp kullanılmadığına ilişkin detayların gürültüde kaybolması muhtemeldir.

Hayır, sonucun geldiğini sanmıyorum. Programınız birden fazla makineye dağıtılmış olsa bile, STL'yi dahili olarak kullanmanın onu modüller arası / proses iletişiminde kullanmaya zorlamasının bir nedeni yoktur.

Aslında, harici arayüzlerin tasarımını baştan beri iç uygulamalardan ayırmanız gerektiğini iddia ediyorum, zira eski içinde dahili olarak kullanılanlarla karşılaştırıldığında değişmesi daha sağlam / zor olacak

Bu sorunun noktasını kaçırıyorsunuz.

Temelde iki tür DLL vardır. Kendiniz ve bir başkasının. "STL problemi", sizin ve onların aynı derleyiciyi kullanmıyor olabileceğidir. Açıkçası, bu kendi DLL dosyanız için bir sorun değil.

DLL'leri aynı kaynak ağacından aynı derleyici ve derleme seçenekleriyle aynı anda oluşturuyorsanız, tamam işe yarayacaktır.

Ancak, bir uygulamayı yeniden kullanılabilen birden fazla parçaya bölmenin "Windows aromalı" yolu COM bileşenleridir . Bunlar küçük (tek tek kontroller veya codec bileşenleri) veya büyük olabilir (IE, mshtml.dll dosyasında COM kontrolü olarak kullanılabilir).

gerektiğinde dinamik olarak yükleme ve daha sonra boşaltma

Bir sunucu uygulaması için bu muhtemelen korkunç bir etkinliğe sahip olacak ; bu yalnızca gerçekten uzun bir zaman diliminde birden fazla aşamadan geçen bir uygulamaya sahip olduğunuzda uygulanabilir, böylece bir daha ne zaman ihtiyaç duyulmayacağını anlayabilirsiniz. Bana bindirme mekanizmasını kullanan DOS oyunlarını hatırlatıyor.

Ayrıca, sanal bellek sisteminiz düzgün çalışıyorsa, kullanılmayan kod sayfalarını arayarak bu işlemi sizin için halledecektir.

bir bilgisayarın artık kaldıramayacağı kadar büyük olabilir

Daha büyük bir PC satın alın.

Unutma , doğru optimizasyon ile bir dizüstü bilgisayar bir hadoop kümesinden daha iyi performans gösterebilir.

Gerçekten birden fazla sisteme ihtiyacınız varsa , seri hale getirme maliyetinin olduğu için aralarındaki sınır hakkında çok dikkatli düşünmeniz gerekir. MPI gibi çerçevelere bakmaya başlamanız gereken yer burasıdır.

Burada, daha büyük ve daha da büyüyen bir sunucu uygulaması üzerinde çalışıyoruz, hatta farklı parçalara bölmeyi düşündüğümüz noktada (DLL dosyaları), gerektiğinde dinamik olarak yükleme ve daha sonra boşaltma işlemleri yapabilmek için performans sorunları.

İlk bölüm mantıklı (performans nedenleriyle farklı makinelere bölme uygulaması).

İkinci bölüm (kütüphanelerin yüklenmesi ve boşaltılması) anlamsızdır, çünkü bu fazladan çaba sarf eder ve (gerçekten) bir şeyleri iyileştirmez.

Tarif ettiğiniz sorun, özel hesaplama makineleriyle daha iyi çözülür, ancak bunlar aynı (ana) uygulama ile çalışmamalıdır.

Klasik çözüm şuna benzer:

[user] [front-end] [machine1] [common resources]
                   [machine2]
                   [machine3]

Ön uç ve hesaplama makineleri arasında, yük dengeleyici ve performans izleme gibi ekstra şeylere sahip olabilirsiniz ve özel makinelerde özel işlem yapmak önbellekleme ve verim optimizasyonları için iyidir.

Bu, hiçbir şekilde DLL'lerin yüklenmesini / boşaltılmasını veya STL ile ilgisi olmadığını gösterir.

Yani, gerektiğinde dahili olarak STL'yi kullanın ve verilerinizi öğeler arasında seri hale getirin (bkz. Grpc ve protokol arabellekleri ve çözdükleri türler).

Bu, sağladığınız sınırlı bilgi ile, bunun klasik xy problemi gibi göründüğünü söyledi (@Graham'ın dediği gibi).