3 puan yazan GN⁺ 2025-10-30 | 1 yorum | WhatsApp'ta paylaş
  • SpiderMonkey motorunun JavaScript·WebAssembly derleme sürecini görselleştirmek için dahili araçlar baştan aşağı yenilendi ve etkileşimli grafikler üreten bir özellik geliştirildi
  • Mevcut Graphviz tabanlı iongraph, kararsız yerleşim ve sezgisel olmayan yapı nedeniyle hata ayıklama verimliliğini düşürüyordu; bunun yerine yeni bir yerleşim algoritması doğrudan tasarlandı
  • Yeni algoritma, Sugiyama yaklaşımını basitleştirerek döngü yapısını net biçimde gösteriyor ve kararlı, hızlı yerleşimi 1000 satırdan kısa JavaScript koduyla uyguluyor
  • Grafikler, okunabilirliği artırmak için demiryolu diyagramı tarzı düz kenarlar kullanıyor ve Graphviz'e kıyasla binlerce kat daha hızlı render hızına ulaşıyor
  • Bu araç Firefox Profiler ile entegre durumda ve ileride arama, register görselleştirme gibi işlevlerle genişletilmesi planlanıyor

SpiderMonkey'in görselleştirme araçlarının yenilenmesi

  • SpiderMonkey'in Ion optimize edici derleyicisi tarafından üretilen dahili grafikleri görselleştirmek için araç yeniden inşa edildi
    • Kullanıcılar bir web sayfasında JavaScript kodu girerek fonksiyon optimizasyon sürecini gerçek zamanlı grafikler üzerinden inceleyebiliyor
    • Grafiklerde sürükleme, yakınlaştırma ve kaydırıcı ile aşama aşama değişiklikler görülebiliyor
  • Eski Graphviz tabanlı iongraph PDF çıktısı üretiyordu, ancak kaynak kod yapısıyla uyuşmuyor ve çıktı kararsızlığı ciddi düzeydeydi
    • Küçük kod değişikliklerinde bile düğüm konumları büyük ölçüde değiştiği için pass'ler arası karşılaştırma zorlaşıyordu
    • Döngü ve koşul yapıları görsel olarak bozulduğu için kontrol akışını anlamak zorlaşıyordu

Graphviz'in sınırları ve yeni yaklaşım

  • Graphviz'in Sugiyama algoritması genel grafik optimizasyonu için uygun olsa da kontrol akış grafiği (CFG) özelliklerini yansıtamıyor
    • JavaScript ve WebAssembly döngüleri yalnızca tek bir giriş noktasına sahip ve reducible kontrol akışı taşıyor
  • SpiderMonkey ekibi bu kısıtları kullanarak basitleştirilmiş, amaca özel bir algoritma tasarladı
    • Döngü kaldırma: loop backedge'leri yok sayma
    • Katmanlama (Leveling): döngüden sonraki blokları aşağıya yerleştirerek kod akışını yansıtma
    • Kesişim azaltmayı atlama: kararlılığı öncelemek için true/false dal sırasını sabitleme
    • Döngü ağacı yapısını koruma: iç içe döngüleri görsel olarak net ifade etme
  • Sonuç olarak yalın, hızlı ve kararlı bir yerleşim elde edildi; ilk uygulama yaklaşık 1000 satır JavaScript'ten oluşuyor

iongraph yerleşim algoritmasının adımları

  • 1. aşama: Katmanlama
    • Bloklar katmanlara göre sıralanıyor ve döngü içi/dışı ilişkiler yansıtılıyor
    • Döngü bittikten sonraki bloklar, tüm döngü yüksekliği kadar aşağıya yerleştiriliyor
  • 2. aşama: Dummy node oluşturma
    • Birden fazla katmanı geçen kenarlara dummy node eklenerek görsel çakışmalar önleniyor
    • Aynı hedefe giden kenarlar birleştirilerek görsel gürültü azaltılıyor
  • 3. aşama: Kenar hizalama (Straighten)
    • Parent ve child düğümler hizalanarak dikey çizgi formu korunuyor, döngü girintisi uygulanıyor
    • Dummy node'lar da hizalama sürecine katılarak çakışma önleme ve yapıyı koruma sağlanıyor
  • 4. aşama: Yatay kenar izleme
    • Yatay kenarlar üst üste binmemesi için track bazında hizalanıyor
    • Kenar yönüne göre üst ve alt olarak ayrılıyor, birleştirilebilen kenarlar tek hatta toplanıyor
  • 5. aşama: Dikey yerleştirme (Verticalize)
    • Her katmana bir Y koordinatı verilerek eşit yükseklikli yerleşim ve daha iyi okunabilirlik sağlanıyor
  • 6. aşama: Render
    • Demiryolu diyagramı tarzı düz kenarlar kullanılıyor
    • Kenarlar yalnızca dikey ve yatay olarak kesişiyor; yön ve yapı açıkça anlaşılıyor

Basit algoritmanın etkisi

  • Karmaşık optimizasyonlar yerine öngörülebilir kural tabanlı yerleşim ile okunabilirlik ve kararlılık sağlandı
    • Düğüm sırasını sabitleyip kenarları sadeleştirerek pass'ler arasında tutarlılık korundu
  • Kısıt çözücü (Constraint Solver) dışarıda bırakılarak insanın daha kolay anlayabileceği bir yapı kuruldu
    • Döngü içi yerleşim veya sonraki blokların aşağı alınması gibi anlam odaklı tasarım mümkün oldu
  • Performans artışı: Graphviz'in 10 dakikada işlediği zlib fonksiyon grafiği 20 milisaniyede render ediliyor
    • Binlerce kat daha yüksek hız ve daha iyi gezinilebilirlik sağlandı

Gelecek planları

  • iongraph, Firefox Profiler ile entegre edildi; performans analizi sırasında grafikler incelenebiliyor
    • Şu anda yalnızca SpiderMonkey shell build'inde kullanılabiliyor, tarayıcı build'ine dahil değil
  • Gelecek için önerilen işlevler
    • Gelişmiş gezinme özellikleri, arama, register allocation görselleştirmesi vb.
    • Net bir yol haritası yok, ancak açık kaynak katkıları memnuniyetle karşılanıyor
  • Yerelde denemek için IONFLAGS=logs ayarıyla /tmp/ion.json oluşturulduktan sonra
    bağımsız dağıtım üzerinden yüklenebiliyor
  • Kaynak kodu GitHub üzerinde açık ve geliştiricilerle doğrudan Matrix sohbet odası üzerinden iletişim kurulabiliyor

1 yorum

 
GN⁺ 2025-10-30
Hacker News görüşleri
  • Karşılaştırmayı doğru yapmak gerekirse bu, Graphviz’in tamamıyla değil dot(1) ile yapılan bir karşılaştırma
    Graphviz, birden fazla yerleşim motoru (dot, neato, fdp, sfdp, circo, twopi vb.) içeren bir görselleştirme çatısıdır
    Yeni önerilen algoritma Graphviz’e katkı olarak eklenirse gerçekten harika olur

    • Biraz kafa karıştırıcı. dot, hem Graphviz’in dil adıdır hem de aynı zamanda yerleşim motorunun adıdır
      İlgili belgeler için Graphviz dil açıklaması ve dot yerleşim motoru dokümanı bağlantılarına bakılabilir
    • iongraph algoritmasının genellenebilirliğinin ne kadar yüksek olacağından emin değilim
      indirgenebilir kontrol akışına sahip kontrol akışı grafikleri (CFG) için iyi çalışabilir, ama çok sayıda karmaşık istisna olacaktır gibi görünüyor
    • iongraph MPL, Graphviz ise EPL lisanslı
      Üstelik iongraph JavaScript tabanlı, bu yüzden Graphviz’e entegre etmek için onu Claude benzeri araçlarla C’ye dönüştürmek gerekir
  • Algoritmanın orijinal uygulamasını doğrudan inceleyebilme becerisi gerçek bir süper güç gibi
    Graphviz ile karmaşık görselleştirmeler yapmış biri olarak, birinin bunu baştan uygulamış olması ilk başta beni şaşırttı
    Ama algoritmanın yapısına bakınca, düşündüğüm kadar karmaşık olmayabileceğini fark ettim
    Yine de gerçek uygulamayı bitirmeden önce gizli karmaşıklıkları görmek zor olmaya devam ediyor

  • Genel bir algoritmayı belirli bir problem alanına uyarlarsanız çok daha iyi sonuçlar alabilirsiniz
    Ama çoğu durumda kolaylık olsun diye genel amaçlı algoritmayı olduğu gibi kullanıyoruz

    • Ben de bu konuda bir makale yazdım
      Belirli bir uygulamaya göre uyarlanmış sistem tasarımı, performans, ölçeklenebilirlik ve hata toleransı açısından büyük iyileşmeler sağlıyor
      Ama 1000 kat iyileştirme peşine düşerseniz 1-2 yıl çok hızlı geçiyor
    • Buna katılıyorum, ama bazı alanlarda ‘basit algoritmalar’ aslında daha iyi çalışabiliyor
      Genel grafik yerleşim sistemleri çok daha fazla durumu ele almak zorunda olduğu için kaçınılmaz olarak karmaşıklaşıyor
      Bu yüzden girdiyi analiz edip özel durumlarda hızlı algoritmaları, diğer durumlarda ise garantili genel algoritmaları kullanmak iyi bir denge olabilir diye düşünüyorum
  • Güzel bir yazıydı. Bu arada Graphviz’in dot’u Sugiyama algoritmasının saf bir uygulaması değil
    Gerçek uygulama sitenin makalesinde ayrıntılı biçimde anlatılıyor
    Büyük grafiklerde dot ile iongraph’ı karşılaştıran görsellere bakınca, dot’un alanı en aza indirmeye optimize edildiği, iongraph’ın ise buna odaklanmadığı görülüyor
    Büyük grafik görselleştirmeleri şık görünüyor ama pratikte gerçekten işe yaradıkları durumlar nadir

    • Büyük grafik görselleştirmeleri bir tür ‘katran çukuru fikri’ gibi — başta çekici geliyor ama pratikte neredeyse hep başarısız oluyor
      Görselleştirme ancak birkaç düzine düğüme kadar işe yarıyor; sonrasında kenar karmaşıklığı yüzünden anlamak zorlaşıyor
      Sonuçta yalnızca basit örneklerde iyi çalışıyor, karmaşık ortamlarda ise daha çok engel oluyor
    • Ben de büyük grafiklerden çok fazla fayda çıkmadığını düşünüyorum
      Problemlerin çoğu daha küçük parçalara indirgenebiliyor
      Ama Graphviz küçük grafiklerde bile estetik açıdan pek iyi değil, iongraph ise çizgi okunabilirliği bakımından çok daha iyi
      Uzun vadede arama, vurgulama/gizleme özellikleri gibi etkileşimli öğelere ihtiyaç olduğunu düşünüyorum
    • Ben de aynı fikirdeyim. İlgili yazı için On Layers and Boxes and Lines bağlantısına bakın
      Diyagramların bağlantı verememesi veya bağlantı alamaması sınırlaması sinir bozucu
      Mermaid’de metin bağlantıları mümkün ama diyagram bağlantıları sınırlı
      StackOverflow’daki ilgili tartışma da bakmaya değer
      Bu tür özelliklerin tasarım aşamasında birinci sınıf özellik olarak ele alındığı araçlara ihtiyaç var
    • CMake’in bağımlılık grafiği de Graphviz kullanıyor, ama büyük diyagramlarda kısmi yakınlaştırma/uzaklaştırma ile gezinme kesinlikle gerekli
  • Graphviz’in asıl gücü dot dili
    dot ile tanımlanan grafikler araçlar arası uyumluluk bakımından çok güçlü, sözdizimi de basit ve okunabilir
    Mermaid gibi alternatifler ortaya çıkmış olsa da dot hâlâ standart bir biçim olarak uzun süre yaşamaya devam edecek gibi görünüyor

    • “Statüko en iyisidir! Çünkü o statükodur.” esprisini hatırlattı
  • Gerçekten harika bir yazıydı
    Acaba bu tür teknikler D2’nin TALA yerleşim motorunda da kullanıldı mı, merak ediyorum
    TALA örneklerine bakın

  • Grafik çizimiyle ilgileniyorsanız Will Evans’ın derslerini (bağlantı) tavsiye ederim
    Ben geçmişte Open Graph Drawing Framework(OGDF) için Dot lexer’daki bir hataya düzeltme katkısı yapmıştım,
    OGDF, Graphviz’e göre daha az kesişim üreten ve daha hızlı çalışan algoritmalar uyguluyor
    Benim deneyimime göre OGDF’nin çıktıları çok daha temizdi
    İlgili PR kayıtları için GitHub bağlantısına bakılabilir

  • İlginç. Örneklerin nasıl çalıştırıldığını merak ediyorum

  • Bu projenin güzel yanı, web istemcisi ortamını temel alan etkileşimli keşfi desteklemesi
    Kontrol akışı grafiklerine (CFG) özel bir yerleşim olduğundan alana özel görselleştirme mümkün
    Graphviz’de de çoklu çizgi, kenar sırası kontrolü gibi özellikler var ama dokümantasyonu zayıf
    Brandes ve Kopf’un kenar yönlendirme algoritması entegre edilse iyi olurdu
    Graphviz neredeyse 40 yıllık bir proje ve bugün onu esasen ikinci nesil birkaç gönüllü sürdürüyor
    Araç geliştirmek her zaman zor bir pazar oldu; kullanıcılar zeki ama bütçesi düşük ekiplerde yer alıyor
    Bildirimsel 2B diyagram araçlarının yavaş ilerleyen gelişimi üzücü

  • Bu alanda çalışan herkese her zaman +1 destek
    Ben de mermaid ve graphviz kullandım ama sonunda yine FigJam’e döndüm — okunabilirlik ve estetik kalite daha yüksek
    graphviz devasa bir ikili dosya, mermaid ise tarayıcı SVG işleme bağımlılığı yüzünden kullanışsız
    İhtiyaç duyulan şey, metinle kolayca diyagram oluşturmayı sağlayan basit bir araç

    • Bu araçların sorunu, düğüm sayısı arttığında okunmasının zorlaşması
      Yazarın önerdiği yaklaşımın bu ödünleşimi kontrol etmeye yönelik iyi bir deneme olduğunu düşünüyorum
    • Ben mermaid ile otomatik üretilmiş proje dokümanı kullandım ve oldukça iyi çalıştı
      Döngüleri ele almaması dışında memnundum
      SVG/HTML çıktısı, stil düzenleme ve kopyalama açısından avantajlı
    • D2’ye de bakılabilir. Yakın zamanda HN ana sayfasına çıkan yazı buna örnek
    • graphviz kodunun ne kadar büyük olduğunu merak edip baktım; 250 binden fazla satır çıktı
      Metin tabanlı bir diyagram aracı istiyorsanız TikZ tavsiye ederim
      TikZ vikisine bakabilirsiniz
      Ama FigJam’deki gibi anlık görsel geri bildirim yok
    • Ben resvg-js(bağlantı) ile dagre/graphlib(bağlantı) kombinasyonunu kullanarak render almayı başardım
      mermaid’in aşırı bağımlılıkları ve kod tutarlılığının zayıf olması hoşuma gitmedi
      Bunun yerine nomnoml(bağlantı) daha temiz bir koda sahip ve ayrıca Typescript’e taşınmış graphre(bağlantı) de var
      mermaid’i resvg-js ile birlikte kullanmak için SVG metin genişliği ölçümü ile ilgili bir yeniden düzenleme gerekiyor