Mengevaluasi performa

Gunakan Simpleperf untuk mengevaluasi kinerja perangkat. Simpleperf adalah alat pembuatan profil bawaan untuk aplikasi dan proses native di Android. Gunakan CPU Profiler untuk memeriksa penggunaan CPU aplikasi dan aktivitas thread secara real time.

Ada dua indikator performa yang terlihat oleh pengguna:

  • Performa yang dapat diprediksi dan terlihat. Apakah pengguna antarmuka (UI) menurunkan frame atau merender secara konsisten pada 60FPS? Apakah audio diputar tanpa artefak atau pop-up? Berapa lama penundaan antara pengguna menyentuh layar dan efek yang ditampilkan di layar?
  • Durasi waktu yang diperlukan untuk operasi yang lebih lama (seperti membuka aplikasi).

Yang pertama lebih terlihat daripada yang kedua. Pengguna biasanya melihat jank tetapi tidak dapat mengetahui waktu startup aplikasi antara 500 md vs 600 md kecuali mereka melihat dua perangkat secara berdampingan. Latensi sentuh langsung terlihat dan secara signifikan berkontribusi terhadap persepsi terhadap suatu perangkat.

Akibatnya, di perangkat yang cepat, pipeline UI adalah hal terpenting dalam sistem selain yang diperlukan untuk menjaga pipeline UI tetap berfungsi. Ini berarti pipeline UI harus mendahului pekerjaan lain apa pun yang tidak diperlukan untuk UI yang intuitif. Untuk mempertahankan UI yang lancar, sinkronisasi latar belakang, pengiriman notifikasi, dan semua pekerjaan serupa harus ditunda jika pekerjaan UI dapat dijalankan. Penting dapat diterima untuk mengorbankan kinerja operasi yang lebih lama (runtime HDR+, startup aplikasi, dll.) untuk mempertahankan UI yang lancar.

Kapasitas versus jitter

Saat mempertimbangkan performa perangkat, kapasitas, dan jitter adalah dua metrik yang bermakna.

Kapasitas

Kapasitas adalah jumlah total sumber daya yang dimiliki perangkat lebih dari beberapa waktu. Ini dapat berupa sumber daya CPU, sumber daya GPU, sumber daya I/O, jaringan, bandwidth memori, atau metrik serupa lainnya. Saat memeriksa kinerja sistem secara keseluruhan, ada baiknya untuk memisahkan komponen individu dan mengasumsikan satu metrik yang menentukan performa (terutama saat melakukan perangkat baru karena beban kerja yang berjalan di perangkat tersebut kemungkinan sudah diperbaiki).

Kapasitas sistem bervariasi berdasarkan sumber daya komputasi {i>online<i}. Mengubah frekuensi CPU/GPU adalah cara utama untuk mengubah kapasitas, tetapi ada adalah yang lain seperti mengubah jumlah inti CPU secara {i>online<i}. Oleh karena itu, kapasitas sistem sesuai dengan konsumsi daya; mengubah kapasitas selalu menghasilkan perubahan serupa pada konsumsi daya.

Kapasitas yang dibutuhkan pada waktu tertentu sangat ditentukan oleh aplikasi yang sedang berjalan. Hasilnya, platform tidak bisa berbuat banyak untuk menyesuaikan kapasitas yang dibutuhkan untuk suatu beban kerja, dan sarana untuk melakukannya dibatasi pada peningkatan runtime (framework Android, ART, Bionic, compiler/driver GPU, {i>kernel<i}).

Jitter

Meskipun kapasitas yang dibutuhkan untuk beban kerja mudah dilihat, jitter lebih yang samar-samar. Sebagai pengantar jitter yang baik sebagai penghalang untuk mempercepat yang berbeda, lihat KASUS PERFORMA KOMPUTER SUPER YANG TIDAK ADA: MENCAPAI PERFORMA OPTIMAL PADA 8.192 PROSESOR ASCl Q. (Ini adalah investigasi mengapa ASCI Q superkomputer tidak mencapai kinerja yang diharapkan dan merupakan pengantar pengoptimalan sistem besar.)

Halaman ini menggunakan istilah jitter untuk menjelaskan apa yang disebut makalah ASCI Q noise. {i>Jitter<i} adalah perilaku sistem acak yang mencegah kentara bekerja dari berlari. Sering kali pekerjaan ini harus dijalankan, tetapi mungkin tidak memiliki waktu tertentu yang menyebabkannya dijalankan pada waktu tertentu. Karena hal itu acak, akan sangat sulit untuk menolak keberadaan jitter untuk workload tertentu. Juga sangat sulit untuk membuktikan bahwa sumber yang diketahui dari jitter adalah penyebab masalah performa tertentu. Alat yang paling umum digunakan untuk mendiagnosis penyebab jitter (seperti tracing atau pencatatan) jitternya sendiri.

Sumber jitter yang dialami dalam implementasi Android di dunia nyata termasuk:

  • Penundaan Scheduler
  • Menginterupsi pengendali
  • Kode pengemudi berjalan terlalu lama dengan interupsi atau preemption dinonaktifkan
  • Softirq jangka panjang
  • Pertentangan kunci (aplikasi, framework, driver kernel, binder lock, mmap kunci)
  • Pertentangan deskriptor file di mana thread prioritas rendah menahan kunci pada file, mencegah thread prioritas tinggi berjalan
  • Menjalankan kode penting UI di antrean kerja yang dapat mengalami penundaan
  • Transisi tidak ada aktivitas CPU
  • Logging
  • Keterlambatan I/O
  • Pembuatan proses yang tidak diperlukan (misalnya, siaran CONNECTIVITY_CHANGE)
  • Cache thrashing halaman disebabkan oleh memori bebas yang tidak cukup

Jumlah waktu yang dibutuhkan untuk periode jitter tertentu mungkin atau mungkin tidak menurun seiring dengan meningkatnya kapasitas. Misalnya, jika pengemudi meninggalkan dinonaktifkan selagi menunggu pembacaan dari sekeliling bus i2c, butuh perbaikan jumlah waktu, terlepas dari apakah CPU-nya berada di 384 MHz atau 2 GHz. Meningkat kapasitas bukanlah solusi yang layak untuk meningkatkan kinerja ketika jitter yang terlibat. Akibatnya, prosesor yang lebih cepat biasanya tidak akan meningkatkan performa performa dalam situasi dengan jitter terbatas.

Akhirnya, tidak seperti kapasitas, jitter hampir seluruhnya berada dalam domain vendor sistem.

Konsumsi memori

Konsumsi memori biasanya disebabkan oleh performa yang buruk. Meskipun bukanlah masalah kinerja, itu bisa menyebabkan jitter melalui overhead lowmemorykiller, layanan dimulai ulang, dan page cache thrashing. Lebih rendah konsumsi memori dapat menghindari penyebab langsung dari kinerja yang buruk, tetapi mungkin ada peningkatan lainnya tertarget yang juga menghindari penyebab tersebut (misalnya, menyematkan kerangka kerja untuk mencegahnya agar tidak di-page out saat akan di-page segera setelahnya).

Menganalisis performa awal perangkat

Memulai dari sistem yang fungsional tetapi berperforma buruk dan mencoba memperbaiki perilaku sistem dengan melihat kasus individu buruk yang terlihat oleh pengguna kinerja bukan strategi yang bagus. Karena kinerja yang buruk biasanya tidak mudah direproduksi (yaitu, jitter) atau juga merupakan masalah aplikasi banyak variabel dalam sistem menyeluruh yang mencegah strategi ini menjadi efektif. Sebagai akibatnya, sangat mudah salah mengidentifikasi penyebab dan melakukan perbaikan kecil saat kehilangan peluang sistemik untuk memperbaiki kinerja di seluruh sistem.

Sebagai gantinya, gunakan pendekatan umum berikut saat memunculkan rumusan baru perangkat:

  1. Membuat sistem melakukan booting ke UI dengan semua driver berjalan dan beberapa hal dasar setelan gubernur frekuensi (jika Anda mengubah setelan gubernur frekuensi, ulangi semua langkah di bawah).
  2. Pastikan kernel mendukung tracepoint sched_blocked_reason serta tracepoint lainnya di pipeline tampilan yang menunjukkan kapan frame dikirim ke layar.
  3. Mengambil rekaman aktivitas panjang dari seluruh pipeline UI (dari menerima input melalui IRQ hingga pemindaian akhir) sambil menjalankan beban kerja ringan dan konsisten (misalnya, UiBench atau uji bola di TouchLatensi).
  4. Memperbaiki penurunan frame yang terdeteksi di ringan dan konsisten sebagian besar workload standar dan berbasis cloud.
  5. Ulangi langkah 3-4 hingga Anda dapat menjalankan tanpa penurunan frame selama 20+ detik pada satu waktu.
  6. Lanjutkan ke sumber jank lain yang terlihat oleh pengguna.

Hal-hal sederhana lainnya yang dapat Anda lakukan sejak awal dalam menampilkan perangkat meliputi:

  • Pastikan {i>kernel<i} Anda memiliki sched_blocked_reason patch tracepoint. Tracepoint ini diaktifkan dengan kategori pelacakan sched di systrace dan menyediakan fungsi yang bertanggung jawab untuk tidur saat itu thread memasuki mode tidur tanpa gangguan. Sangat penting untuk analisis performa karena tidur tanpa gangguan adalah indikator yang sangat umum dari {i>jitter<i}.
  • Pastikan Anda memiliki pelacakan yang memadai untuk pipeline GPU dan tampilan. Aktif Qualcomm SOC terbaru, tracepoint diaktifkan menggunakan:
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    Peristiwa ini tetap diaktifkan saat Anda menjalankan systrace sehingga Anda dapat melihat informasi dalam trace tentang display pipeline (MDSS) di mdss_fb0. Di Qualcomm SOCs, Anda tidak akan melihat tambahan tentang GPU dalam tampilan systrace standar, tetapi hasilnya dalam rekaman aktivitas itu sendiri (untuk detailnya, lihat Memahami systrace).

    Yang Anda inginkan dari pelacakan tampilan semacam ini adalah satu peristiwa yang secara langsung menunjukkan bahwa {i>frame<i} telah dikirim ke layar. Dari sana, Anda dapat dapat menentukan apakah Anda berhasil mencapai waktu render frame; jika peristiwa Xn terjadi kurang dari 16,7 md setelah peristiwa Xn-1 (dengan asumsi tampilan 60 Hz), maka Anda tahu bahwa Anda tidak melakukan jank. Jika SOC Anda tidak memberikan sinyal tersebut, harap dengan vendor Anda untuk mendapatkannya. {i>Debugging jitter<i} sangat sulit tanpa sinyal definitif penyelesaian {i>frame<i}.

Menggunakan tolok ukur sintetis

Tolok ukur sintetis berguna untuk memastikan fungsi dasar perangkat tersedia. Namun, memperlakukan benchmark sebagai proxy untuk perangkat yang dirasakan performa AI generatif tidak berguna.

Berdasarkan pengalaman dengan SOC, perbedaan pada tolok ukur sintetis performa di antara SOC tidak berkorelasi dengan perbedaan yang serupa performa UI yang dapat disimak (jumlah frame yang dilepas, frame persentil ke-99 waktu, dll.). Benchmark sintetis adalah tolok ukur khusus kapasitas; dampak jitter performa terukur tolok ukur ini hanya dengan mencuri waktu dari operasi tolok ukur. Akibatnya, skor tolok ukur sintetis sebagian besar tidak relevan sebagai metrik kinerja yang dirasakan pengguna.

Pertimbangkan dua SOC yang menjalankan Benchmark X yang merender 1.000 frame UI dan melaporkan total waktu rendering (skor lebih rendah lebih baik).

  • SOC 1 merender setiap frame Tolok Ukur X dalam 10 md dan skor 10.000.
  • SOC 2 merender 99% frame dalam 1 md, tetapi 1% frame dalam 100 md dan skor 19.900, skor yang jauh lebih baik.

Jika benchmark tersebut menunjukkan performa UI yang sebenarnya, SOC 2 akan menjadi tidak dapat digunakan. Dengan asumsi kecepatan refresh 60 Hz, SOC 2 akan memiliki frame yang mengalami jank setiap 1,5 detik operasi. Sementara itu, SOC 1 (SOC yang lebih lambat menurut Benchmark X) akan berjalan lancar.

Menggunakan laporan bug

Laporan {i>bug<i} terkadang berguna untuk analisis kinerja, tetapi karena sangat berat, sehingga jarang berguna untuk men-debug masalah jank sporadis. Mereka dapat memberikan beberapa petunjuk tentang apa yang dilakukan sistem pada waktu tertentu, terutama jika jank berada di sekitar transisi aplikasi (yang tercatat dalam laporan bug). Laporan bug juga dapat menunjukkan ketika sesuatu lebih luas salah pada sistem yang dapat mengurangi kapasitas efektifnya (seperti throttling atau fragmentasi memori).

Menggunakan TouchLatensi

Beberapa contoh perilaku buruk berasal dari TouchLatensi, yang merupakan pilihan workload berkala yang digunakan untuk Pixel dan Pixel XL. Tersedia di frameworks/base/tests/TouchLatency dan memiliki dua mode: latensi sentuh dan bola yang memantul (untuk beralih mode, klik tombol di pojok kanan atas kanan atas).

Tes bola memantul persis seperti yang terlihat: Bola memantul di sekitar layar selamanya, terlepas dari input pengguna. Biasanya juga sejauh ini pengujian yang paling sulit untuk dijalankan dengan sempurna, namun semakin dekat dijalankan tanpa ada penurunan {i>frame<i}, akan semakin baik perangkat Anda. Tujuan tes memantul bola itu sulit karena mudah, tapi konsisten sekali workload yang berjalan pada clock yang sangat rendah (ini mengasumsikan bahwa perangkat memiliki frekuensi gubernur; jika perangkat sedang berjalan dengan waktu tetap, lakukan {i>downclock<i} pada CPU/GPU hingga mendekati nilai minimum saat menjalankan uji pemantulan bola untuk pertama kalinya). Saat sistem berhenti dan jam turun mendekati tidak ada aktivitas, CPU/GPU yang diperlukan waktu per frame akan meningkat. Anda dapat menonton bola dan melihat hal-hal yang tersendat, dan Anda akan juga bisa melihat frame yang terlewat di systrace.

Karena beban kerja sangat konsisten, Anda dapat mengidentifikasi sebagian besar sumber {i>jitter<i} jauh lebih mudah daripada di sebagian besar beban kerja yang terlihat oleh pengguna dengan melacak apa persis berjalan pada sistem selama setiap frame yang terlewat, bukan UI {i>pipelines<i} yang sama. Jam yang lebih rendah memperkuat efek jitter dengan membuatnya kemungkinan besar jitter apa pun menyebabkan penurunan frame. Hasilnya, Jika TouchLatensi mendekati 60FPS, makin kecil kemungkinan Anda memiliki sistem yang buruk perilaku yang menyebabkan jank sporadis dan sulit direproduksi di laporan aplikasi.

Karena jitter sering (tetapi tidak selalu) memiliki invarian kecepatan jam, gunakan pengujian yang berjalan pada clock yang sangat rendah untuk mendiagnosis jitter karena alasan berikut:

  • Tidak semua jitter adalah invarian kecepatan jam; banyak sumber memakai CPU baik.
  • Gubernur harus mendapatkan waktu render frame rata-rata yang mendekati batas waktu dengan sehingga waktu yang dihabiskan untuk menjalankan pekerjaan non-UI dapat mendorongnya menurunkan {i>frame<i}.