Yazar, Dart kodu için ARM64 assembly tabanlı, resmi tarayıcıdan iki kat daha hızlı bir lexer geliştirdi. Küçük performans farklarını güvenilir bir şekilde ölçmek için istatistiksel yöntemler kullanarak bu başarıya ulaştı. Lexer'ını 104.000 Dart dosyası üzerinde test ettiğinde, asıl performans darboğazının kendi lexer'ı olmadığını, aksine giriş/çıkış (G/Ç) işlemlerinin olduğunu şaşkınlıkla keşfetti. Dosya okuma süreleri, lexing sürelerinin beş katına kadar çıkıyordu ve geliştirilen lexer'ın 2.17 katlık hız artışı, toplam sistem performansına sadece 1.22 katlık bir iyileşme olarak yansıyordu.
Bu durumun nedenini araştırdığında, sorunun SSD'nin kendisi olmadığını fark etti; zira SSD 5-7 GB/s okuma hızına sahipken, sistem sadece 80 MB/s hızında çalışıyordu. Asıl sorun, çok sayıda dosya için yapılan aşırı sistem çağrılarıydı (syscalls). 104.000 dosya için 300.000'den fazla open(), read(), close() sistem çağrısı yapılması gerekiyordu. Her bir sistem çağrısı, kullanıcı alanından çekirdek alanına bağlam anahtarlaması (context switch) ve çekirdek işlemleri gibi ek yükler getirerek 1-5 mikrosaniye gecikmeye neden oluyordu. Bu da sadece sistem çağrılarından kaynaklanan 0.3-1.5 saniyelik bir ek yük anlamına geliyordu.
Yazar, pub.dev'in paketleri neden tar.gz arşivleri olarak depoladığını bu noktada anladı: daha az sistem çağrısı yapmak. Hipotezi, 104.000 ayrı dosya yerine, her paketi tek bir tar.gz arşivi halinde sıkıştırarak sistem çağrısı sayısını 1.351'e düşürmekti. Bu yöntemle hem dosya sayısı büyük ölçüde azaldı hem de 1.13 GB'lık veri 169 MB'a sıkıştırılarak 6.66 katlık bir alan tasarrufu sağlandı. Bu yaklaşım, G/Ç performansındaki gerçek iyileşmeyi ortaya koydu.
Yüksek performanslı kod yazarken bile, sistem çağrılarının ve G/Ç optimizasyonunun, ham işlem gücünden daha kritik bir darboğaz olabileceği anlaşıldı.