Sorun: Kod, binlerce minik parçadan oluşur
Bir kod dosyasını renkli göstermek (syntax highlighting) için her kelime, her parantez ayrı bir HTML parçasına dönüşür. Birkaç bin satırlık bir dosya, on binlerce DOM öğesi demek. Bir de bunu React gibi bir kütüphaneden geçirirsen, aynı yapının bir kopyası da bellekte tutulur.
Yapay zekâ ajanları işi büyüttü. Bir ajan tek seferde 10.000 satırlık değişiklik getirebiliyor. GitHub’ın büyük pull request’lerde yavaşlaması da bu yüzden sık konuşuluyor.
Pierre Computer ekibi bu sorun için iki açık kaynak kütüphane yazdı: Değişiklikleri (diff) gösteren diffs ve dosya ağacını gösteren Trees. İkisi de belli bir framework’e bağlı değil. React, Vue ya da düz JavaScript ile kullanılabiliyor. Konuklara göre diffs, Codex ve Claude’un masaüstü uygulamalarında kullanılıyor.
Teknik 1: Sadece görüneni çiz
Temel fikir sanallaştırma (virtualization). Ekranda 30 satır görünüyorsa, sayfada da sadece o 30 satır ve biraz fazlası bulunur. Kaydırdıkça eski satırlar silinir, yenileri eklenir.
Trees için verilen örnek etkileyici: Android’in açık kaynak kodundaki yaklaşık 1,5 milyon dosya takılmadan kaydırılabiliyor. Hepsi için DOM oluşturulsa, konuklara göre bu yarım dakika kadar sürerdi. Kural basit: Kullanıcı görmüyorsa, hesaplama bile yapma.
Teknik 2: Kaydırma hızına yetişemezsen, boş ekran gösterme
Tarayıcı kaydırmayı JavaScript’ten ayrı, ekran kartı üzerinde yapar. Bu yüzden akıcıdır. Ama çok hızlı kaydırırsan JavaScript yeni satırları zamanında koyamaz ve bir an boş ekran görürsün.
Amadeus De Marzi’nin çözümü CSS’teki position: sticky özelliğini ters kullanmak. Kod bloğu, görünen alanın kenarına “yapışıyor”. JavaScript geride kalsa bile ekranda bir önceki içerik duruyor. Boş ekran yerine yarım saniye eski bir görüntü görüyorsun, sonra doğrusu geliyor.
Teknik 3: Ağır işi arka plana at
Renklendirme, hızlı bir kütüphaneyle bile büyük bir dosyada 100 milisaniye sürebilir. Bu, ekranın bir an takılması için yeterli. diffs bu işi bir Web Worker’a, yani ayrı bir iş parçacığına veriyor. Önce düz metin hemen gösteriliyor, renkler hazır olunca ekleniyor. Çoğu zaman bu geçiş fark edilmiyor bile.
Teknik 4: Önce tahmin et, sonra düzelt
Sanallaştırmanın zor kısmı, kaydırma çubuğunun doğru boyda olması. Bunun için toplam yüksekliği bilmen gerekir. Ama 8 milyon satırı tek tek ölçmek çok uzun sürer. Çözüm: Satır sayısı ile satır yüksekliğini çarpıp hızlı bir tahmin yap. Bir bölüm gerçekten çizildiğinde ölç, tahmin yanlışsa düzelt ve sonucu sakla. Kaydırma konumunu korumak için de ekrandaki ilk satır “çapa” olarak kullanılıyor.
Metin yüksekliğini tahmin etmek yerine DOM’a dokunmadan hesaplamanın bir yolunu Pretext yazısında anlattık.
Tarayıcı bunu kendisi yapamaz mı?
CSS’te content-visibility özelliği, ekran dışındaki içeriğin çizimini atlıyor. Ama DOM öğeleri yine bellekte duruyor. Konuklara göre asıl sınır bu: 150 MB’lık bir Linux diff’ini sayfaya koymak, çizilmese bile tarayıcıyı zorluyor. Tarayıcıların bir sayfanın yüksekliğine koyduğu bir üst sınır da var.
Bedeli de var: Sanallaştırılmış bir sayfada tarayıcının kendi “sayfada bul” (Ctrl+F) özelliği çalışmıyor. Çünkü aradığın satır sayfada yok. Ekip bunu kendi arama tuşuyla çözüyor ve hâlâ iyi bir yol aradığını söylüyor.
Düşün
- Kullandığın uygulamalarda hangi listeler sanallaştırılmış olabilir? Ctrl+F orada çalışıyor mu?
- “Görünmüyorsa hesaplama” kuralını kendi projende nerede uygulayabilirsin?
Videoyu izle
Kaynaklar (4, İngilizce)
Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.