Signal Tabanlı Uygulamalarda Bellek ve Bağımlılık Grafiği Nasıl Yönetilir?

Reaktif programlama sistemlerinde Signal, Computed ve Effect gibi yapıların birbirleriyle olan ilişkileri, temelde bir yönlendirilmiş grafik (directed graph) olarak modellenir. Bu grafik, uygulamanın veriler arasında nasıl bağ kurduğunu ve değişikliklerin nasıl yayıldığını belirleyen temel bir yapıdır. Peki, bu grafiği doğru yönetmek neden bu kadar önemlidir?

Günümüzde kullanılan popüler framework’lerden React, Vue ve Svelte gibi araçlar, reaktif sistemlerin performansını optimize etmek için bu grafiği kullanır. Ancak grafiğin etkin bir şekilde yönetilmesi, yalnızca performansı değil, aynı zamanda bellek kullanımını da doğrudan etkiler. Bu yazıda, bağımlılık grafiğinin nasıl çalıştığını ve bellek yönetimindeki rolünü detaylandıracağız.

Bağımlılık Grafiği Neden Gereklidir?

Bir reaktif sistemde, signal (durum kaynağı), computed (türetilmiş değer) ve effect (yan etki) arasındaki ilişkiler, birbirlerine olan bağımlılıklarıyla tanımlanır. Bu ilişkiler, bir grafik olarak temsil edilir:

• Düğümler (Nodes): Her bir reaktif bileşen bir düğüm olarak kabul edilir.
• Signal: Uygulamanın temel durumunu temsil eder.
• Computed: Diğer düğümlerden türetilmiş değerleri hesaplar.
• Effect: DOM güncellemeleri, log kaydı veya harici sistemlerle senkronizasyon gibi yan etkileri yönetir.

• Kenarlar (Edges): Bağımlılık ilişkilerini gösterir. Örneğin, bir effect bir signal okuduğunda, aralarında bir kenar oluşur. Bu sayede sistem, bir düğümün değişmesi durumunda kimlerin bilgilendirilmesi gerektiğini bilebilir.

Grafiğin Avantajları

1. Hassas Güncellemeler: Bir signal değiştiğinde, sistem tüm uygulamayı değil, yalnızca ilgili düğümleri ve onların bağımlılıklarını günceller. Bu, gereksiz hesaplamaları ve performans kayıplarını önler.

1. Tekrarlı Hesaplamaların Önlenmesi: Grafik, hangi hesaplamaların geçersiz kaldığını ve hangilerinin hâlâ geçerli olduğunu takip eder. Böylece sistem, yalnızca gerekli olduklarında hesaplamaları yeniden yürütür.

Eğer böyle bir grafik olmasaydı, sistem her değişiklikte tüm bileşenleri yeniden hesaplamak zorunda kalırdı. Bu da büyük ölçekli uygulamalarda ciddi performans sorunlarına yol açardı.

Bellek Yönetimindeki Kritik Sorunlar

Grafik yapısı, reaktif sistemlerde sahiplik (ownership) ve ömür döngüsü (lifetime) gibi önemli kavramları da beraberinde getirir. Grafik, sadece veri yapılarından ibaret değildir; aynı zamanda düğümler arasındaki referansları da içerir. Bu referanslar doğru yönetilmediğinde, bellek sızıntıları ortaya çıkar.

1. Dolaşım Referansları ve Bellek Sızıntıları

Bir düğümün artık kullanılmadığı durumlarda bile grafik tarafından tutulması, bellek sızıntılarına neden olabilir. Bu genellikle şu senaryolarda görülür:

• Bir React bileşeni ekrandan kaldırıldığında.
• Vue bileşeni yok edildiğinde.
• Elle oluşturulan bir effect artık kullanılmadığında.
• Türetilmiş bir hesaplama artık erişilemez hale geldiğinde.

Bu durumlarda, düğümün grafikten çıkarılması gerekir. Aksi takdirde, sistem gereksiz yere bellek tüketmeye devam eder.

Çözüm: Bir düğüm kullanım dışı bırakıldığında, tüm bağımlılıklarını da grafikten silmek gerekir. Bu, yalnızca gelecekteki hesaplamaları durdurmakla kalmaz, aynı zamanda düğümü bellekten serbest bırakır.

2. Geçersiz Kenarlar ve Performans Kaybı

Bir düğümün bağımlılık ilişkisi değiştiğinde, grafikteki eski kenarlar geçersiz hale gelebilir. Örneğin:

const value = computed(() => {
  if (enabled.get()) {
    return sourceA.get();
  }
  return sourceB.get();
});

Burada, enabled değeri true iken value sourceA ye bağımlıdır. Ancak enabled false olduğunda, value artık sourceA ye bağımlı olmamalıdır. Eğer eski kenar grafikte kalırsa, sourceA değiştiğinde value gereksiz yere yeniden hesaplanır.

Çözüm: Bağımlılıklar yeniden toplandıktan sonra, grafikteki eski kenarlar silinmeli ve yeni bağımlılıklar eklenmelidir. Bu işlem, genellikle link ve unlink operasyonlarıyla gerçekleştirilir.

3. JavaScript’in Çöp Toplayıcısı ve Döngüsel Referanslar

JavaScript’in çöp toplayıcısı, birçok döngüsel referansı otomatik olarak temizleyebilir. Ancak, reaktif bir sistemde, grafiğin kendi yapısı nedeniyle bazı düğümler hâlâ bellekte kalabilir.

Örneğin, bir düğümün hem yukarı hem de aşağı akışta referansları varsa, bu düğümün bellekten serbest bırakılması zorlaşabilir. Bu durumda, aşağıdaki stratejiler yardımcı olabilir:

• Çift yönlü sahiplikten kaçınmak: Düğümler arasındaki referansları tek yönlü olarak tutmak.
• Açık şekilde imha etmeyi desteklemek: Yaşam döngüsü sınırları net olan durumlarda düğümleri elle imha etmek.
• Metadata için WeakMap kullanmak: Çöp toplayıcının düğümleri serbest bırakmasına izin vermek.
• WeakRef kullanmak: Yalnızca gerekli durumlarda zayıf referanslar kullanmak.

Bu yaklaşımlardan en basit ve anlaşılır olanı, açık şekilde imha etmeyi desteklemektir. Bu, yaşam döngüsü sınırlarını daha net hale getirir ve bellek yönetimini kolaylaştırır.

Minimal Bir Grafik Yapısı Örneği

Bir sinyal sisteminde, grafiğin yönetiminden sorumlu olan özel bir Grafik Katmanı bulunur. Bu katman, düğümleri, bağımlılıkları, aboneleri ve imha işlemlerini yönetir. Basit bir düğüm yapısı şu şekilde olabilir:

export interface Node {
  deps?: Set<Node>;       // Yukarı akış bağımlılıkları
  subs?: Set<Node>;       // Aşağı akış aboneleri
  stale?: boolean;        // Düğümün kirli olup olmadığı
  disposed?: boolean;     // Düğümün imha edilip edilmediği
}

Farklı kütüphaneler, düğümleri farklı şekillerde organize edebilir, ancak temel fikir genellikle aynıdır. Önemli olan, grafiğin dinamik olarak güncellenebilmesi ve bellek sızıntılarını önleyecek şekilde tasarlanmasıdır.

Sonuç ve Gelecek Adımlar

Reaktif sistemlerde bellek yönetimi ve bağımlılık grafiği, uygulamanın performansı ve güvenilirliği için kritik öneme sahiptir. Doğru bir grafik yapısı, yalnızca güncellemelerin hassas bir şekilde yapılmasını sağlamakla kalmaz, aynı zamanda bellek kullanımını da optimize eder.

Gelecekte, bu konulara daha derinlemesine eğilen framework’ler ve geliştiriciler, reaktif programlamayı daha da verimli hale getirebilir. Özellikle, açık şekilde imha etme mekanizmalarının standartlaşması ve zayıf referansların daha stratejik kullanımı, bu alanda önemli gelişmelere yol açabilir.

Reaktif programlamanın sunduğu avantajlardan tam olarak faydalanmak için, bu temel kavramları anlamak ve uygulamak şarttır.