Bu belge, uygulamanızdaki önemli performans sorunlarını belirleyip düzeltmenize yardımcı olur.
Temel performans sorunları
Uygulamaların kötü performans göstermesine yol açabilecek birçok sorun vardır, ancak uygulamanızda dikkat etmeniz gereken bazı yaygın sorunlar şunlardır:
- Başlatma gecikmesi
Başlatma gecikmesi, uygulama simgesine, bildirime veya başka bir giriş noktasına dokunma ile kullanıcı verilerinin ekranda gösterilmesi arasında geçen süredir.
Uygulamalarınızda aşağıdaki başlangıç hedeflerini hedefleyin:
500 ms'den kısa sürede baştan başlatma. Başlatılan uygulama, çalıştırılmakta olan uygulama sistemin belleğinde olmadığında gerçekleşir. Bu durum, uygulama yeniden başlatmadan sonra ilk başlatıldığında veya uygulama işlemi kullanıcı ya da sistem tarafından durdurulduğunda gerçekleşir.
Buna karşılık, uygulama arka planda çalışırken hazır başlatma gerçekleşir. Soğuk başlatma, depolama alanındaki her şeyi yükleyip uygulamanın başlatılması gerektiğinden sistem üzerinde en fazla çalışma yapılmasını gerektirir. Baştan başlatmanın 500 ms veya daha kısa sürmesini deneyin.
P95 ve P99 gecikmeleri ortanca değere çok yakındır. Uygulamanın başlatılması uzun sürerse kullanıcı deneyimini olumsuz etkiler. Uygulama başlatmanın kritik yolu sırasında işlemler arası iletişimler (IPC'ler) ve gereksiz G/Ç, kilit anlaşmazlığıyla karşılaşabilir ve tutarsızlıklara yol açabilir.
- Kaydırma engeli
Jank, sistem tarafından istenen 60 Hz veya daha yüksek kadansta çerçeveler oluşturamadığında ve kareler sağlayamadığında ortaya çıkan görsel kesintiyi tanımlayan terimdir. Jank'ı en çok kaydırma sırasında görünürken, akıcı bir şekilde animasyonlu bir akış yerine hızlanmalar yaşanır. Uygulamanın içeriği oluşturması, sistemdeki bir karenin süresinden daha uzun sürdüğü için Jank, hareket boyunca bir veya daha fazla kare boyunca hareket durakladığında görünür.
Uygulamalar 90 Hz yenileme hızlarını hedeflemelidir. Geleneksel oluşturma hızları 60 Hz'dir ancak yeni çoğu cihaz, kaydırma gibi kullanıcı etkileşimleri sırasında 90 Hz modunda çalışır. Bazı cihazlar 120 Hz'e kadar olan daha yüksek hızları destekler.
Bir cihazın belirli bir zamanda hangi yenileme hızını kullandığını görmek için Hata Ayıklama bölümünde Geliştirici Seçenekleri > Yenileme hızını göster'i kullanarak bir yer paylaşımı etkinleştirin.
- Düzgün olmayan geçişler
Bu durum, sekmeler arasında geçiş yapma veya yeni bir etkinlik yükleme gibi etkileşimler sırasında belirgindir. Bu tür geçişler, akıcı animasyonlar olmalı ve gecikme veya görsel titreme içermemelidir.
- Güç verimsizlikleri
İş yapmak pil şarjını azaltır ve gereksiz işler yapmak pil ömrünü kısaltır.
Kodda yeni nesneler oluşturulmasından kaynaklanan bellek ayırmaları, sistemde önemli işler yapılmasının nedeni olabilir. Bunun nedeni, ayırma işlemlerinin yalnızca Android Çalışma Zamanı (ART) tarafından çaba gerektirmesi değil, bu nesnelerin daha sonra boşaltılması (çöp toplama) için de zaman ve çaba gerektirmesidir. Hem ayırma hem de toplama, özellikle geçici nesneler için çok daha hızlı ve daha verimlidir. Eskiden mümkün olduğunca nesne ayırmaktan kaçınmak en iyi uygulamaydı ancak uygulamanız ve mimariniz için en mantıklı olanı yapmanızı öneririz. ART'ın yapabildiği şeyler göz önünde bulundurulduğunda, tahsislerden tasarruf edilmesinin sağlanamayacak kod riski altında olması en iyi uygulama değildir.
Bununla birlikte, bu işlem çaba gerektirir. Bu nedenle, iç döngünüzde çok sayıda nesne ayırırsanız performans sorunlarına katkıda bulunabileceğini unutmayın.
Sorunları belirleme
Performans sorunlarını belirlemek ve düzeltmek için aşağıdaki iş akışını öneririz:
- Aşağıdaki kritik kullanıcı yolculuklarını belirleyin ve inceleyin:
- Başlatıcı ve bildirimler de dahil olmak üzere yaygın başlatma akışları.
- Kullanıcının veriler arasında gezindiği ekranlar.
- Ekranlar arasındaki geçişler.
- Gezinme veya müzik çalma gibi uzun süreli akışlar.
- Aşağıdaki hata ayıklama araçlarını kullanarak önceki akışlar sırasında neler olduğunu inceleyin:
- Perfetto: Hassas zamanlama verileriyle cihaz genelinde neler olduğunu görmenize olanak tanır.
- Bellek Profil Aracı: Yığında hangi bellek ayırmalarının gerçekleştiğini görmenize olanak tanır.
- Simpleperf: Hangi işlev çağrılarının belirli bir süre boyunca en fazla CPU'yu kullandığını gösteren bir alev grafiği. Systrace'te uzun sürecek bir şey tespit ettiğinizde ama nedenini bilmediğinizde Simpleperf size ek bilgiler sağlayabilir.
Bu performans sorunlarını anlamak ve hata ayıklamak için her bir test çalıştırmasında manuel olarak hata ayıklamak büyük önem taşır. Birleştirilmiş verileri analiz ederek önceki adımları değiştiremezsiniz. Bununla birlikte, kullanıcıların gerçekte ne gördüğünü anlamak ve regresyonların ne zaman olabileceğini belirlemek için otomatik testlerde ve sahada metrik toplamayı ayarlamak önemlidir:
- Başlatma akışları
- Alan metrikleri: Play Console başlatma süresi
- Laboratuvar testleri: Macrobenchmark ile test başlatma
- Jank
- Alan metrikleri
- Play Console çerçeve verileri: Play Console'da metrikleri belirli bir kullanıcı yolculuğuna indirgeyemezsiniz. Yalnızca uygulama genelindeki genel olumsuzlukları raporlar.
FrameMetricsAggregator
ile özel ölçüm: Belirli bir iş akışı sırasında jank metriklerini kaydetmek içinFrameMetricsAggregator
kullanabilirsiniz.
- Laboratuvar testleri
- Macrobenchmark ile kaydırma.
- Macrobenchmark, tek bir kullanıcı yolculuğunu temsil eden
dumpsys gfxinfo
komutlarını kullanarak kare zamanlamasını toplar. Bu, belirli bir kullanıcı yolculuğundaki olumsuzlukları anlamanın bir yoludur. Karelerin çizilmesinin ne kadar sürdüğünü gösterenRenderTime
metrikleri, regresyonları veya iyileştirmeleri tanımlamak için hatalı karelerin sayısından daha önemlidir.
- Alan metrikleri
Uygulama Bağlantıları doğrulama sorunları
Uygulama Bağlantıları, web sitenize ait olduğu doğrulanan web sitenizin URL'sini temel alan derin bağlantılardır. Aşağıda, App Link doğrulamalarının başarısız olmasına yol açabilecek nedenler belirtilmiştir.
- Intent filtresi kapsamları: Yalnızca uygulamanızın yanıt verebileceği URL'ler için intent filtrelerine
autoVerify
ekleyin. - Doğrulanmamış protokol anahtarları: Doğrulanmamış sunucu tarafı ve alt alan adı yönlendirmeleri, güvenlik riski olarak kabul edilir ve doğrulamada başarısız olur. Tüm
autoVerify
bağlantılarının başarısız olmasına neden olurlar. Örneğin, HTTPS bağlantılarını doğrulamadan HTTP'den HTTPS'ye (ör. example.com'dan www.example.com'a) yönlendirmek doğrulama işleminin başarısız olmasına neden olabilir. Amaç filtreleri ekleyerek Uygulama Bağlantılarını doğruladığınızdan emin olun. - Doğrulanamayan bağlantılar: Test amacıyla doğrulanamayan bağlantılar eklemek, sistemin uygulamanızın uygulama bağlantılarını doğrulamamasına neden olabilir.
- Güvenilir olmayan sunucular: Sunucularınızın, istemci uygulamalarınıza bağlanabildiğinden emin olun.
Uygulamanızı performans analizi için ayarlama
Bir uygulamadan doğru, tekrarlanabilir ve işlem yapılabilir karşılaştırmalar elde etmek için ayarları doğru şekilde yapmak önemlidir. Gürültü kaynaklarını bastırarak, üretime olabildiğince yakın bir sistemde test yapın. Aşağıdaki bölümlerde, bir test kurulumu hazırlamak için uygulayabileceğiniz, APK'ya ve sisteme özgü bazı adımlar gösterilmektedir. Bu adımlardan bazıları kullanım alanına özgüdür.
İzleme noktaları
Uygulamalar, kodları için özel izleme etkinlikleri kullanabilir.
İzler yakalanırken izleme işlemi, bölüm başına yaklaşık 5 μs'lik küçük bir ek yük oluşturur. Bu nedenle, izlemeyi her yöntemin yanına koymayın. 0,1 ms'den büyük iş parçalarının takibi, performans sorunları hakkında önemli bilgiler sağlayabilir.
APK ile ilgili dikkat edilmesi gereken noktalar
Hata ayıklama varyantları, yığın örnekleriyle ilgili sorunların giderilmesi ve yığın örneklerinin simgeselleştirilmesi açısından faydalı olabilir ancak performansı ciddi şekilde etkiler. Android 10 (API Düzeyi 29) ve sonraki sürümleri çalıştıran cihazlar, sürüm derlemelerinde profil oluşturmayı etkinleştirmek için manifestlerinde profileable android:shell="true"
'i kullanabilir.
Üretim düzeyindeki kod küçültme yapılandırmanızı kullanın. Uygulamanızın kullandığı kaynaklara bağlı olarak, bu durum performans üzerinde önemli bir etki yaratabilir. Bazı ProGuard yapılandırmaları izleme noktalarını kaldırdığından, üzerinde testleri çalıştırdığınız yapılandırma için bu kuralları kaldırmayı düşünebilirsiniz.
Derleme
Cihazda uygulamanızı bilinen bir durumla (genellikle speed
veya speed-profile
) derleyin. Arka plan tam zamanında (JIT) etkinlik, performansta önemli ölçüde ek yüke neden olabilir. Test çalıştırmaları arasında APK'yı yeniden yüklüyorsanız bu durumla sık sık karşılaşırsınız. Aşağıda bu işlemi gerçekleştirmek için kullanılabilecek bir komut verilmiştir:
adb shell cmd package compile -m speed -f com.google.packagename
speed
derleme modu, uygulamayı tamamen derler. speed-profile
modu, uygulamayı, uygulama kullanımı sırasında toplanan, kullanılan kod yollarının profiline göre derler. Profilleri tutarlı ve doğru bir şekilde toplamak zor olabilir. Bu nedenle, profilleri kullanmaya karar verirseniz bunların beklediğiniz bilgileri topladığını doğrulayın. Profiller şu konumda bulunur:
/data/misc/profiles/ref/[package-name]/primary.prof
Macrobenchmark doğrudan derleme modunu belirtmenizi sağlar.
Sistemle ilgili olarak göz önünde bulundurulması gerekenler
Düşük düzey ve yüksek doğrulukta ölçümler için cihazlarınızı kalibre edin. Aynı cihazda ve aynı işletim sistemi sürümünde A/B karşılaştırmaları çalıştırın. Aynı cihaz türünde bile performansta önemli farklılıklar olabilir.
Root erişimli cihazlarda Microbenchmark'lar için bir lockClocks
komut dosyası kullanabilirsiniz. Bu komut dosyaları, diğer işlevlerinin yanı sıra şunları yapar:
- CPU'ları sabit bir frekansa yerleştirin.
- Küçük çekirdekleri devre dışı bırakın ve GPU'yu yapılandırın.
- Termal kısıtlamayı devre dışı bırakın.
Uygulama başlatma, DoU testi ve jank testi gibi kullanıcı deneyimi odaklı testler için lockClocks
komut dosyası kullanmanızı önermeyiz ancak Mikrobenchmark testlerinde gürültüyü azaltmak için gerekli olabilir.
Mümkün olduğunda, ölçümlerinizdeki gürültüyü azaltabilecek ve ölçümlerin yanlışlığını önleyebilecek Macrobenchmark gibi bir test çerçevesi kullanmayı düşünün.
Yavaş uygulama başlatma: Gereksiz trambolin etkinliği
Trambolin etkinliği, uygulama başlatma süresini gereksiz yere uzatabilir. Bu nedenle, uygulamanızın bunu yapıp yapmadığını bilmeniz önemlidir. Aşağıdaki örnek izlemede gösterildiği gibi bir activityStart
hemen ardından başka bir activityStart
gelir ve ilk etkinlik hiçbir kare çizmez.
Bu durum hem bildirim giriş noktasında hem de normal bir uygulama başlatma giriş noktasında gerçekleşebilir. Genellikle yeniden düzenleme yaparak bu sorunu çözebilirsiniz. Örneğin, bu etkinliği başka bir etkinlik çalıştırılmadan önce kurulumu gerçekleştirmek için kullanıyorsanız bu kodu yeniden kullanılabilir bir bileşene veya kitaplığa dahil edin.
GC'leri sık tetikleyen gereksiz ayırmalar
Çöp toplamaların (GC'ler), Systrace'te beklediğinizden daha sık gerçekleştiğini görebilirsiniz.
Aşağıdaki örnekte, uzun çalışan bir işlem sırasında her 10 saniyede bir, uygulamanın zaman içinde gereksiz ama tutarlı bir şekilde ayırma yapabileceğini gösterir:
Ayrıca, Bellek Profil Aracı'nı kullanırken ayırmaların büyük çoğunluğunu belirli bir çağrı yığınının oluşturduğunu fark edebilirsiniz. Kodun bakımını zorlaştırabileceği için tüm ayırmaları agresif bir şekilde ortadan kaldırmanız gerekmez. Bunun yerine, tahsislerin hotspot'ları üzerinde çalışarak başlayın.
Janky çerçeveler
Grafik ardışık düzeni nispeten karmaşıktır ve kullanıcının nihayetinde düşen kare görüp görmeyeceğini belirlemede bazı farklılıklar olabilir. Bazı durumlarda platform, arabelleğe alma özelliğini kullanarak bir çerçeveyi "kurtarabilir". Bununla birlikte, sorunlu kareleri uygulamanız açısından tanımlamak için bu nüansların çoğunu göz ardı edebilirsiniz.
Uygulamanın çok az işlem yapması gerekmeden kareler çizildiğinde 60 FPS'lik bir cihazda Choreographer.doFrame()
izleme noktaları 16, 7 ms'lik bir kadansta oluşur:
Uzaklaştırıp izde gezinirseniz bazen karelerin tamamlanmasının biraz daha uzun sürdüğünü görebilirsiniz. Yine de kendilerine ayrılan 16,7 ms. süreden daha uzun sürmedikleri için sorun olmaz:
Bu düzenli kadansta bir kesinti olduğunda bu, Şekil 5'te gösterildiği gibi stabil bir karedir:
Bunları tespit ederek alıştırma yapabilirsiniz.
Bazı durumlarda, hangi görünümlerin şişirildiği veya RecyclerView
uygulamasının ne yaptığı hakkında daha fazla bilgi için izleme noktasını yakınlaştırmanız gerekir. Bazı durumlarda ise
daha ayrıntılı inceleme yapmanız gerekebilir.
Titreyen çerçeveleri belirleme ve bunların nedenlerini ayıklama hakkında daha fazla bilgi edinmek için Yavaş oluşturma bölümüne bakın.
Yaygın RecyclerView hataları
RecyclerView
yedekleme verilerinin tamamının gereksiz yere geçersiz kılınması, uzun kare oluşturma sürelerine ve gecikme yaşanmasına yol açabilir. Bunun yerine, güncellenmesi gereken görüntüleme sayısını en aza indirmek için yalnızca değişen verileri geçersiz kılın.
İçeriğin tamamen değiştirilmesi yerine güncellenmesine neden olan maliyetli notifyDatasetChanged()
çağrılarından kaçınmanın yolları için Dinamik verileri sunma konusuna bakın.
İç içe yerleştirilmiş her RecyclerView
öğesini düzgün bir şekilde desteklemezseniz dahili RecyclerView
her seferinde tamamen yeniden oluşturulabilir. Görünümlerin her bir iç RecyclerView
arasında geri dönüştürülebilmesi için iç içe yerleştirilmiş her RecyclerView
öğesinde bir RecycledViewPool
ayarlanmış olmalıdır.
Yeterli veriyi önceden getirmemek veya zamanında getirmemek, kullanıcının sunucudan daha fazla veri beklemesi gerektiğinde kaydırma listesinin sonuna ulaşmayı sarsabilir. Bu teknik açıdan olumsuz olmasa da hiçbir çerçeve için son tarih kaçırılmadığından, önceden getirme zamanlamasını ve miktarını değiştirerek kullanıcı deneyimini önemli ölçüde iyileştirebilirsiniz. Böylece, kullanıcı verileri beklemek zorunda kalmaz.
Uygulamanızda hata ayıklama
Aşağıda, uygulamanızın performansıyla ilgili hata ayıklama yöntemleri yer almaktadır. Sistem izleme ve Android Studio profil aracını kullanmaya genel bir bakış için aşağıdaki videoyu izleyin.
Systrace ile uygulama başlatmada hata ayıklama
Uygulama başlatma işlemine genel bir bakış için Uygulama başlatma süresi bölümüne ve sistem izlemeye genel bakış için aşağıdaki videoyu izleyin.
Başlangıç türlerini aşağıdaki aşamalarda netleştirebilirsiniz:
- Sıfırdan başlatma: Kayıtlı durumu olmayan yeni bir işlem oluşturmaya başlayın.
- Hazır başlatma: İşlemi yeniden kullanırken etkinliği yeniden oluşturur ya da kaydedilen durumda işlemi yeniden oluşturur.
- Çalışır durumda başlatma: Etkinliği yeniden başlatır ve enflasyon düzeyinde başlar.
Systra'ları Cihazdaki Sistem İzleme uygulamasıyla yakalamanızı öneririz. Android 10 ve sonraki sürümlerde Perfetto'yu kullanın. Android 9 ve önceki sürümlerde Systrace'i kullanın. İzleme dosyalarını web tabanlı Perfetto izleme görüntüleyici ile görüntülemenizi de öneririz. Daha fazla bilgi için Sistem izlemeye genel bakış bölümüne bakın.
Dikkat etmeniz gereken bazı noktalar şunlardır:
- Çakışmayı izleme: Monitörle korunan kaynaklar için rekabet, uygulamanın başlatılmasında önemli ölçüde gecikmeye neden olabilir.
Eşzamanlı bağlayıcı işlemleri: Uygulamanızın kritik yolunda gereksiz işlemleri arayın. Gerekli bir işlem pahalıysa iyileştirmeler yapmak için ilgili platform ekibiyle birlikte çalışmayı düşünün.
Eşzamanlı GC: Bu yaygın bir durumdur ve nispeten düşüktür. Ancak bu durumla sık karşılaşıyorsanız Android Studio bellek profil aracını kullanarak konuyu inceleyebilirsiniz.
G/Ç: Başlatma sırasında gerçekleştirilen G/Ç'yi kontrol edin ve uzun tezgahlar olup olmadığına bakın.
Diğer iş parçacıklarında önemli etkinlik: Bunlar, kullanıcı arayüzü iş parçacığını etkileyebilir. Bu nedenle, başlatma sırasında arka planda çalışmaya dikkat edin.
Daha iyi uygulama başlatma metriği raporlaması için uygulama açısından başlatma tamamlandığında reportFullyDrawn
numaralı telefonu çağırmanızı öneririz. reportFullyDrawn
kullanımı hakkında daha fazla bilgi için Tam görüntüleme süresi bölümüne bakın.
Perfetto iz işlemcisini kullanarak RFD tarafından tanımlanan başlangıç zamanlarını ayıklayabilirsiniz. Bu durumda, kullanıcı tarafından görülebilen bir izleme etkinliği yayınlanır.
Cihazda Sistem İzlemeyi kullan
Bir cihazda sistem izini yakalamak için Sistem İzleme adlı sistem düzeyinde uygulamayı kullanabilirsiniz. Bu uygulama, cihazı takmak veya adb
cihazına bağlamak zorunda kalmadan cihazdaki izleri kaydetmenize olanak tanır.
Android Studio Bellek Profili Aracı'nı kullanma
Bellek sızıntılarından veya hatalı kullanım kalıplarından kaynaklanabilecek bellek basıncını incelemek için Android Studio Bellek Profil Aracı'nı kullanabilirsiniz. Nesne ayırmalarının canlı görünümünü sağlar.
GC'lerin neden ve ne sıklıkta gerçekleştiğini izlemek için Bellek Profili Aracı'ndaki bilgileri takip ederek uygulamanızdaki bellek sorunlarını düzeltebilirsiniz.
Uygulama belleğini profillemek için aşağıdaki adımları uygulayın:
Bellek sorunlarını algılama.
Odaklanmak istediğiniz kullanıcı yolculuğuna ait bellek profili oluşturma oturumunu kaydedin. Şekil 7'de gösterildiği gibi, nesne sayısında artış olup olmadığına bakın. Bu, Şekil 8'de gösterildiği gibi sonunda GC'lere yol açar.
Bellek baskısına neden olan kullanıcı yolculuğunu tanımladıktan sonra bellek baskısının temel nedenlerini analiz edin.
Bellekte baskı olan sıcak noktaları teşhis edin.
Şekil 9'da gösterildiği gibi, hem Ayırma Sayısı'nı hem de Sığ Boyut'u görselleştirmek için zaman çizelgesinde bir aralık seçin.
Bu verileri sıralamanın birden fazla yolu vardır. Aşağıda, her bir görünümün sorunları analiz etmenize nasıl yardımcı olabileceğine ilişkin bazı örnekler verilmiştir.
Sınıfa göre düzenle: Önbelleğe alınan veya bir bellek havuzundan yeniden kullanılan nesneler oluşturan sınıfları bulmak istediğinizde kullanışlıdır.
Örneğin, bir uygulamanın saniyede "Vertex" adlı 2.000 sınıf nesne oluşturduğunu görürseniz Allocations (Ayırma Sayısı) her saniyede 2.000 artar ve bunu sınıfa göre sıralama yaparken görürsünüz. Atık oluşturmamak için bu nesneleri yeniden kullanmak istiyorsanız bellek havuzu uygulayın.
Çağrı yığınına göre düzenle: Belleğin ayrıldığı sıcak yolun nerede olduğunu bulmak istediğinizde (ör. bir döngü içinde veya çok fazla ayırma işi yapan belirli bir işlevin içinde) faydalıdır.
Sığ Boyut: Yalnızca nesnenin kendisinin belleğini izler. Çoğunlukla yalnızca temel değerlerden oluşan basit sınıfları izlemek için yararlıdır.
Tutulan Boyut: Nesneden kaynaklanan toplam belleği ve yalnızca nesnenin başvurduğu referansları gösterir. Karmaşık nesneler nedeniyle bellek basıncını takip etmek açısından yararlıdır. Bu değeri elde etmek için şekil 10'da gösterildiği gibi tam bir bellek dökümünü alın. Ardından, Şekil 11'de gösterildiği gibi Tutulan Boyut sütunu bir sütun olarak eklenir.
Optimizasyonun etkisini ölçün.
GC'ler daha belirgindir ve bellek optimizasyonlarının etkisini ölçmek daha kolaydır. Optimizasyon, bellek baskısını düşürdüğünde daha az GC görürsünüz.
Optimizasyonun etkisini ölçmek için profil oluşturucu zaman çizelgesinde GC'ler arasındaki süreyi ölçün. Bu durumda, GC'ler arasında sürenin daha uzun olduğunu görebilirsiniz.
Bellek iyileştirmelerinin nihai etkileri şunlardır:
- Uygulama, bellek baskısına sürekli olarak etki etmezse bellek dışı kapanmalar muhtemelen daha az olur.
- Daha az GC'ye sahip olmak, özellikle P99'da jank metriklerini iyileştirir. Bunun nedeni, GC'lerin CPU anlaşmazlığına yol açarak GC gerçekleşirken oluşturma görevlerinin ertelenmesidir.
Sizin için önerilenler
- Not: JavaScript kapalıyken bağlantı metni gösterilir
- Uygulama başlatma analizi ve optimizasyonu {:#app-startup-analysis-OPT}
- Donmuş kare
- Macrobenchmark yazma