Ruby’nin JSON optimizasyonu, Bölüm 1

Aslında bir alternatife gerek yok

• ruby/json, oj'den biraz daha yavaştır, ancak aradaki fark büyük değildir.
• oj, performansı nedeniyle popülerdir, ancak çeşitli sorunlara yol açabilir.
• oj'nin sorunlarından biri, Oj.mimic_JSON aracılığıyla yapılan monkey patch nedeniyle ortaya çıkan güvenlik sorunlarıdır.

Monkey patch sorumluluğu

• Oj.mimic_JSON ve Oj.optimize_rails, JSON'un daha az verimli uygulamasının yerini alır, ancak sorunlara neden olabilir.
• Örneğin script_safe seçeneğini yok sayarak XSS saldırılarına karşı savunmasız hale getirebilir.
• Monkey patch dikkatle yapılmalı ve API'nin evrimine paralel olarak güvenli şekilde ele alınmalıdır.

Kararsızlık

• oj, büyük ölçekli üretim ortamlarında Ruby çökmesinin başlıca nedenlerinden biriydi.
• oj çok aktif biçimde geliştirildiği için yeni çökmeler sık sık ortaya çıkıyordu.
• oj'nin kod tabanında güvenilmesi zor, kirli hack'ler bulunuyordu.

Temel çalışma

• ruby/json'u oj'ye benzer performansa getirerek monkey patch ihtiyacını azaltmak amaçlandı.
• Benchmark kuruldu ve performansı analiz etmek için C profiler kullanıldı.

Yinelenen kontrollerden kaçınma

• JSON.dump benchmark'ında yinelenen UTF-8 kontrolleri önlenerek performans iyileştirildi.
• rb_enc_str_asciionly_p ile isLegalUTF8 arasındaki yinelenen iş kaldırılarak %3 performans artışı sağlandı.

Önce daha ucuz ve daha olası koşulları kontrol etme

• fbuffer_inc_capa işlevinde, tamponun zaten ayrılmış olup olmadığını denetleyen koşul optimize edilerek %15 performans artışı sağlandı.

Kurulum maliyetini azaltma

• ruby/json'un kurulum maliyeti azaltılarak mikro benchmark'larda performans ciddi biçimde iyileştirildi.

Pointer takibinden kaçınma

• rb_enc_get çağrısı kaldırılarak performans %8 iyileştirildi.

Arama tablosu

• Arama tablosu kullanılarak JSON string dump performansı %30 iyileştirildi.

Devam edecek

• Daha fazla optimizasyon var, ancak bunlar bir sonraki yazıda ele alınacak.

[GN⁺]

Hacker News görüşleri

• Rails’in varsayılan jbuilder kullanımı, JSON render etmesini yavaşlatan etkenlerden biri

  • Büyük kısmı jbuilder ile render etmek hızı düşürüyor

• Yeni sürümün Twitter JSON dökümünü parse etme/kodlama süresiyle ilgili bilgi olup olmadığı merak ediliyor

• Bu konudaki yazı çok kolay anlaşılır ve Ruby kodunu benchmark edip optimize etme isteği uyandırıyor

  • Yazara teşekkür ediliyor

• Harika bir yazı ve çalışma

  • Bundan sonra Oj kullanmak için hâlâ bir neden olup olmadığı merak ediliyor

• Oldukça ilgi çekici bir yazı

  • Ruby’ye özgü olmayan optimizasyonlarda, örneğin escape karakterleri için bir lookup table kullanırken, neden zaten var olan simdjson gibi kütüphanelerden yararlanılmadığı merak ediliyor

• byroot’un çalışmalarına hayranlık duyuluyor

  • Katkıları ve üretkenliği her zaman şaşırtıcı bulunuyor
  • Ruby-core çalışmalarına katılmak isteniyor ama kendi becerilerine uygun bir alan bulunamadığı için motivasyon düşüyor
  • Ruby C tarafında çalışan kişiler daha sık yazsa, Ruby’yi daha da geliştirebilecek becerilere sahip daha çok insan ortaya çıkardı

• C profiler tavsiyesi harikaydı

  • Ruby gem’ine C kodu ekleyerek optimizasyonu tekrar denemek isteniyor

• Mame’in PR’ında kullanılan "lookup table" adlı performans hilesi etkileyiciydi

  • String#each_char yerine String#each_codepoint kullanmak GC yükünü azaltabilir

• Kendi kod tabanında performansı daha da artıran bir örnek paylaşılıyor

  • Kod noktalarını toplayıp Stringe dönüştürmek için Array#pack kullanılıyor

• Modern CPU’larda branch prediction hint’leri işe yaramıyor

• Ruby JSON’un intrinsic kullanıp kullanmadığı merak ediliyor

  • Çeşitli JIT’lerle uyumluluğu da merak ediliyor