C# ile Garbage Collection baskısını azaltalım

.Net gibi yönetilen dillerde bellek genellikle hunharca kullanılır, nasıl olsa arkamızdan temizleyen var. Bu temizliği yapan Çöp Toplayıcısı (Garbage Collector - GC) oluyor. Heap üzerinde oluşturduğumuz objelere yapılmış referansları takip edip, belli durumlarda kullanım dışı kalanları bizim için bellekten atıyor. Ancak düşük bellekli sistemlerde, çok yoğun obje oluşturulan programlarda bu yaklaşım performansa gözle görülür etki edebiliyor.

Garbage Collection hakkında hızlıca bilgi edinmek için şu yazıya bakabilirsiniz.

Peki neler yapabiliriz?

1 - Dinamik koleksiyonlara kapasite vermek

.Net Framework bize çok yetenekli List, Dictionary, HashSet gibi birçok koleksiyon tipi sağlıyor. Bu tiplerin hepsi dinamik kapasiteye sahip, gerektiği durumlarda büyüyüp küçülebiliyorlar.

Bu yaklaşımda sık kullanılan bir taktik ikiye katlamadır, kapasite dolduğunda varolan eleman sayısı kadar bellek ile kapasite büyütülür. Örneğin bir List‘e ilk elemanı eklediğinizde kapasitesi 4 olacaktır, 4. elemanı eklediğinizde ise kapasite 8 yapılacak vb..

Böylece 1000 elemanı bir listeye tek tek eklediğinizde ne kadar sık ekstra bellek isteneceğini ve her bellek isteğinin fragmantasyon gibi ek maliyetlere sebep olabileceğini düşündüğünüzde gereksiz çok vakit harcandığını tahmin edersiniz.

[Benchmark]
public void Dynamic () {
    var list = new List<int> ();
    for (var i = 0; i < 1000; i++) {
        list.Add (i);
    }
}

[Benchmark]
public void Planned () {
    var list = new List<int> (1000);
    for (var i = 0; i < 1000; i++) {
        list.Add (i);
    }
}

Yukarıdaki iki örnek için alacağımız sonuçlar aşağıdaki gibi olacak:

_{Bu arada benim gibi MarkDown tablosu oluşturmaya bile üşeniyorsanız bu siteyi kullanın}

Tabii kapasiteyi önceden ayarlayabilmek için bu değeri bilmemiz gerekiyor :)

2 - ArrayPool kullanınmı

Yeni oluşturduğumuz her dizi ileride çöp toplayıcıya bir ek iş çıkaracaktır. Fazla uzun ömürlü olmayan diziler için, nedense yazılımcılar arasında çok da bilinmeyen ve temeli bir tasarım şablonuna dayanan ArrayPool kullanarak oluşturduğumuz yükü azaltabiliriz.

Programlama dillerinde serileştirme, şifreleme gibi işlemler yaparken bol bol bayt dizilerini oluşturup sağa sola parametre yollamamız gerekir. Bu diziler de genelde kısa sürede gerekli dönüşümü yaşadıktan sonra kullanım dışı kalırlar ve GC tarafından toplanmak üzere bellekte yer işgal ederler.

Bu tür durumlarda System.Buffers.ArrayPool sınıfını kullanarak (genelde daha çok bilinen ThreadPool ile yaptığımız gibi) işimiz bitince geri teslim etmek üzere bellek kiralayabiliriz.

[Benchmark]
public void RegularArray () {
    var array = new int[1000];
}

[Benchmark]
public void SharedArray () {
    var pool = ArrayPool<int>.Shared;
    var array = pool.Rent (1000);
    // işimiz bitince diziyi iade ediyoruz
    pool.Return (array);
}

1000 elemanlık bir liste için aşağıdaki gibi bir performans alıyoruz:

3 - Class yerine Struct (aman dikkat, sadece doğru yerlerde)

Struct‘lar çok tartışmalı bir konu, çoğunuzdan bir iş görüşmesinde sınıflarla arasındaki farkı cevaplamanız istenmiş olabilir (ben bile istemiş olabilirim, belki yüz kere sordum bu soruyu :)) Önemli özelliklerini sayalım:

• Bir sınıfın parçası olmadıklarında sadece Stack üzerinde yer alırlar, dolayısıyla GC gerektirmez
• Bir sınıf içinde olduklarında da bellekte takip edilmesi gereken ayrı bir obje olmazlar, veri olarak sınıf için ayrılan bellekte yaşarlar
• Bazı arka plan mekanizmalarından dolayı (MethodTable ve ObjectHeader olmaması gibi, CLR via C# okumanızı şiddetle tavsiye ederim) daha az bellek harcarlar

En önemlisi Struct referans değil veri olarak taşınır, yani her atama yaptığınızda yeni bir kopyası oluşur. Dolayısıyla yeni kopya üzerindeki bir alanı değiştirmek eski Struct‘ı etkilemez. O yüzden Microsoft bize aşağıdaki kurallar sağlanıyorsa Struct kullanmamızı tavsiye eder.

• Eğer boyut 16 bayt ya da daha küçükse (kopyalama maliyeti çok artmasın)
• Kısa ömürlü ise
• Değiştirilemez (immutable) ise. Biraz önce açıkladığım sorunu kökten çözmek için
• Sık sık kutulanmayacaksa (ahahah bazen bilerek zorla Türkçe yazıyorum, burada kastedilen boxing)

Doğru kullanıldığında nasıl etkisi oluyormuş görelim:

 class VectorClass {
    public int X { get; set; }
    public int Y { get; set; }
}

struct VectorStruct {
    public int X { get; set; }
    public int Y { get; set; }
}

[Benchmark]
public void WithClass () {
    var vectors = new VectorClass[1000];
    for (int i = 0; i < 1000; i++) {
        // her seferinde Heap üzerinden bellek alınıyor
        vectors[i] = new VectorClass ();
        vectors[i].X = 5;
        vectors[i].Y = 10;
    }
}

[Benchmark]
public void WithStruct () {
    // bu aşamada tüm bellek hazır, tekrar yer istenmiyor
    var vectors = new VectorStruct[1000];
    for (int i = 0; i < 1000; i++) {
        vectors[i].X = 5;
        vectors[i].Y = 10;
    }
}

4 - Sonlandırıcı (Finalizer) kullanmaktan kaçının

Finalizer bir Sylvester Stallone filmi değil (eminim, şimdi kontrol ettim çünkü ben de şüphelendim :)). Çoğunlukla kullanmamız gerekmeyen, GC tam bizim sınıfımızı temizlerken araya girip kendi temizliğimizi yapmamıza izin veren bir sistem. Evdeki bilgisayarınız her temizlenmek üzereyken size haber verip tarayıcı geçmişinizi silmenize izin veren bir yapı gibi düşünebilirsiniz 🙃

Ancak aşağıdaki sebeplerden biraz maliyetli:

• Finalizer içeren her sınıf bir nesil atlatılır (yukarıdaki linki hala okumadınız mı?). Bu da en hızlı temizlik yapılan Gen 0 ile toplanamayacakları anlamına gelir.
• Bir de bu sınıflar Finalizer kuyruğuna eklenir. Kuyrukların ne kadar zaman aldığını ülkemizdeki tecrübelerimizden biliyoruz. Dedike edilmiş bir Thread tarafından temizlenir (bankada tek vezne çalışması gibi, bu benzetmeler umarım işe yarıyordur 😊). Bu durum da uzun çalışan Finalizer’ların hata fırlatmasına sebep olabilir.

Oynatalım Uğurcum:

class Simple {
    public int X { get; set; }
}

class SimpleWithFinalizer {

    ~SimpleWithFinalizer () { }

    public int X { get; set; }
}

private static Simple _instance1;
private static SimpleWithFinalizer _instance2;

[Benchmark]
public void AllocateSimple () {
    for (int i = 0; i < 100000; i++) {
        _instance1 = new Simple ();
    }
}

[Benchmark]
public void AllocateSimpleWithFinalizer () {
    for (int i = 0; i < 100000; i++) {
        _instance2 = new SimpleWithFinalizer ();
    }
}

Bazen Finalizer kaçınılmaz olabiliyor Dispose Pattern, bu durumlarda temizliği kendimiz yaparak kapıya “Odamı Temizleme” kağıdı asmamız gerekiyor.

public void Dispose() {
	Dispose(true);
	GC.SuppressFinalize(this); // finalizer çağırılmasın
}

5 - StackAlloc ile kısa ömürlü diziler

StackAlloc ile Heap’e bulaşmadan Stack üzerinde, dolayısıyla GC baskısı yaratmadan bellek ayırabiliyoruz (çok da hızlı oluyor). Ancak sınıfları (yani genel olarak referans tipleri) kullanamıyoruz, ilkel değerler ve struct’lar (yani değer tipleri) kullanabiliyoruz.

struct VectorStruct {
    public int X { get; set; }
    public int Y { get; set; }
}

[Benchmark]
public void WithNew () {
    var vectors = new VectorStruct[5];
    for (var i = 0; i < 5; i++) {
        vectors[i].X = 5;
        vectors[i].Y = 10;
    }
}

[Benchmark]
public unsafe void WithStackAlloc () {
    var vectors = stackalloc VectorStruct[5];
    for (var i = 0; i < 5; i++) {
        vectors[i].X = 5;
        vectors[i].Y = 10;
    }
}

[Benchmark]
public void WithSpan () {
    Span<VectorStruct> vectors = stackalloc VectorStruct[5];
    for (var i = 0; i < 5; i++) {
        vectors[i].X = 5;
        vectors[i].Y = 10;
    }
}

Fark açık, tabii artık elimizde Spanvar, unsafe işlere girmektense Span kullanmanızı tavsiye ederim. Tesadüfe bakın ki önceden bu konuda yazmıştım.

6 - StringBuilder dedi statik kod analiz aracı

Çoğumuz statik kod analiz araçları kullanmışızdır (Sonarqube, Coverity, Sourcemeter gibi), bu araçların en çok uyarı çıkardığı konu genelde string birleştirme işini toplama yerine StringBuilder ile yap oluyordur. Genelde es geçilen bu teknik borçlar hadi artık temizleyelim dediğinizde aylar sürebilir.

Öncelikle neden string‘leri toplamak sorun oluyor? string özel bir tip, bir referans tipi ama immutable. Yani her değişikliğinizde eski değer GC’nin temizlemesi için bırakılırken bellekte yepyeni bir alan ayrılıyor. Bu da çok fazla string işleminde GC üzerinde sağlam baskı olacağını gösteriyor. Dikkat edilebilecek noktalar:

• Eğer performans arttırmak için bu işe kalkışıyorsanız önce ölçüm yapmalısınız. 10-15 kadar toplama işleminin StringBuilder‘dan daha hızlı olabileceğini göreceksiniz.
• StringBuilder ilk kapasitesini ayarlayabilirseniz daha da verimli çalışacaktır.
• Aynı StringBuilder objesini tekrar tekrar kullanarak daha da performans elde edebilirsiniz. Kodun okunurluğunu azaltmama adına sadece döngü gibi küçük kapsamlı yerlerde kullanmak faydalı olacaktır.

7 - String Interning mi? O nedir?

.Net platformunun pek bilinmeyen bir string optimizasyonu vardır, ilk değerleri aynı atanmış iki string için tek bir referans kullanır.

string a = "Test";
string b = "Test";

a ve b iki farklı değişken gibi görünse de aynı belleği gösteren ortak referanslar olacaklar. Bu işleme String Interning deniyor. Bize iki faydası var:

• Aynı değere sahip iki string için ortak obje kullanarak bellekten kazanıyoruz
• string‘ler karşılaştırılırken öncelikle referans’a sonra değere bakılır. Aynı referansa sahip iki string karşılaştırıldığında değerlerini karşılaştırmak gerekmeden eşit olduklarını anlayabileceğimizden zaman kazanıyoruz.

Derleyicinin eşit değere sahip string‘leri tespit etmesi pahalı bir işlem. Bu yüzden çalışma zamanında bu işlem hiç yapılmaz. Ancak çalışma zamanı bu işi kendimiz el ile yapabiliriz. string.Intern(string) varolan string ile aynı referansı kullanmasını sağlayıp, string.IsInterned(string) ile de aynı değeri gösterip göstermediklerini kontrol edebilirsiniz.

private readonly string s1 = "Hello";
private readonly string s2 = " World";

[Benchmark]
public void WithoutInterning () {
    var s1 = GetNonLiteral ();
    var s2 = GetNonLiteral ();
    for (var i = 0; i < 1000; i++) {
        var x = s1.Equals (s2);
    }
}

[Benchmark]
public void WithInterning () {
    var s1 = string.Intern (GetNonLiteral ());
    var s2 = string.Intern (GetNonLiteral ());
    for (var i = 0; i < 1000; i++) {
        var x = s1.Equals (s2);
    }
}

private string GetNonLiteral () => s1 + s2;

100 tekrarlı bir ölçüm yaptığımızda:

10 tekrarlı bir ölçüm yaptığımızda ise:

Buradan Intern işleminin çok maliyetli olduğunu ve karşılaştırma işine oranla Intern işlemi arttığında ciddi performans kaybı yaşadığımızı görebiliriz.

Optimizasyon çalışmalarını bir yerlerden faydalı olduğunu duyduğumuz için yapmamalıyız, deneyler ile detaylı ölçümlememiz şart.

Kodlar burada: https://github.com/umutozel/gc-pressure-benchmark

Yabancı birçok kaynakta bulunabilecek tavsiyeleri kendimce yorumlamaya çalıştım, umarım faydalı olmuştur.

Michael Shpilt’e yazısı ve başlıkları kullanmama izin verdiği için teşekkürler.

Mutlu kodlamalar!

Referanslar

• Pro .NET Performance: Optimize Your C# Applications (Expert’s Voice in .NET)
• Michael Shpilt’in yazısı
• CLR via C#