Feldera platformunda bir müşteri, yeni bir kullanım senaryosunun mevcut veri işleme boru hatlarıyla aynı miktarda veriyi işlemesine rağmen beklenenden çok daha yavaş çalıştığını bildirdi. Bu durum, Feldera mühendislerini performans sorununu araştırmaya itti. Feldera, kullanıcıların SQL tabloları olarak tanımladığı giriş verilerini ve SQL görünümleri olarak tanımladığı çıkış verilerini, sorguyu artımlı olarak değerlendiren bir Rust programına derler. Bu süreçte, her bir SQL tablosu satırı, Rust'ta bir struct'a dönüştürülür.
Performans düşüşüne neden olan iş yükünde, müşterinin SQL tablosu tanımı yüzlerce sütun içeriyordu ve bu sütunların neredeyse tamamı NULL değer alabiliyordu. SQL'deki NULL değer alabilen sütunlar, Rust'ta Option<T> türüne karşılık gelir. Dolayısıyla, sistem yüzlerce Option<T> alanına sahip devasa Rust struct'ları ile çalışmak zorunda kalıyordu. Programcılar genellikle struct'ları basit, hızlı ve öngörülebilir bulsa da, bu özel durumda büyük ve çok sayıda Option içeren struct'lar beklenmedik performans sorunlarına yol açtı.
Makale, bu tür büyük struct'ların bellek düzenini inceleyerek sorunun kökenine iniyor. Option<T> türlerinin bellek üzerinde nasıl yer kapladığı ve hizalandığı, özellikle yüzlerce kez tekrarlandığında, toplam bellek boyutunu ve erişim sürelerini önemli ölçüde artırabilir. Bu durum, veri işleme hızını düşürerek performansı olumsuz etkileyen temel faktörlerden biri haline gelmiştir. Bu vaka, basit görünen struct kullanımlarının bile belirli senaryolarda karmaşık performans sorunlarına yol açabileceğini gösteriyor.
Basit veri yapıları olarak görülen `struct`'ların, özellikle çok sayıda isteğe bağlı alan içerdiğinde, karmaşık sistemlerde ciddi performans darboğazlarına yol açabileceğini gösteriyor.