Secara umum seberapa sering dan kapan saya harus mengoptimalkan kode saya?

Pada langkah normal 'optimasi pemrograman bisnis sering dibiarkan sampai benar-benar diperlukan. Berarti Anda tidak boleh optmize sampai benar-benar dibutuhkan.

Ingat apa yang dikatakan Donald Knuth "Kita harus melupakan efisiensi kecil, katakanlah sekitar 97% dari waktu: optimasi prematur adalah akar dari semua kejahatan"

Kapan waktu untuk mengoptimalkan untuk memastikan saya tidak membuang-buang usaha. Haruskah saya melakukannya pada level metode? Tingkat kelas? Tingkat modul?

Juga apa yang harus saya ukur optimasi? Kutu? Frame Rate? Total Waktu?

Di tempat saya bekerja, kami selalu menggunakan beberapa tingkat profil; jika Anda melihat masalah, Anda hanya perlu sedikit ke bawah daftar sampai Anda mengetahui apa yang terjadi:

• "Profiler manusia", alias hanya bermain game ; apakah itu terasa lambat atau "hambatan" sesekali? Melihat animasi tersentak-sentak? (Sebagai pengembang, perhatikan bahwa Anda akan lebih peka terhadap beberapa jenis masalah kinerja dan tidak memperhatikan yang lain. Rencanakan pengujian tambahan yang sesuai.)
• Nyalakan tampilan FPS , yang merupakan jendela geser rata-rata 5 detik FPS. Sangat sedikit overhead untuk dihitung dan ditampilkan.
• Nyalakan bilah profil , yang hanya serangkaian paha depan (warna ROYGBIV) yang mewakili berbagai bagian bingkai (mis. Vblank, preframe, pembaruan, tabrakan, render, postframe) menggunakan timer "stopwatch" sederhana di sekitar setiap bagian kode . Untuk menekankan apa yang kami inginkan, kami menetapkan satu bar lebar layar untuk mewakili bingkai target 60Hz, sehingga sangat mudah untuk melihat apakah Anda mis. 50% di bawah anggaran (hanya setengah bar) atau 50% lebih dari ( batang membungkus dan menjadi satu setengah batang). Ini juga cukup mudah untuk mengetahui apa yang umumnya memakan sebagian besar frame: red = render, yellow = update, dll ...
• Bangun instrumen khusus yang memasukkan "stopwatch" seperti kode di sekitar setiap fungsi. (Perhatikan bahwa Anda dapat mengambil hit kinerja, dcache, dan icache besar-besaran ketika melakukan ini, jadi itu pasti mengganggu. Tetapi jika Anda tidak memiliki profiler pengambilan sampel yang tepat atau dukungan yang layak pada CPU, ini adalah pilihan yang dapat diterima. Anda juga bisa menjadi pintar tentang merekam minimal data pada fungsi, masuk / keluar dan membangun kembali jejak panggilan nanti.) Ketika kami membangun milik kami, kami menirukan banyak format output gprof .
• Yang terbaik dari semuanya, jalankan sampling profiler ; VTune dan CodeAnalyst tersedia untuk x86 dan x64, Anda memiliki berbagai simulasi atau lingkungan emulasi yang mungkin memberi Anda data di sini.

(Ada kisah menyenangkan dari GDC tahun lalu tentang seorang programmer grafis yang mengambil empat gambar dirinya - bahagia, acuh tak acuh, jengkel, dan marah - dan menampilkan gambar yang sesuai di sudut internal builds berdasarkan framerate. The pembuat konten dengan cepat belajar untuk tidak mengaktifkan shader yang rumit untuk semua objek dan lingkungan mereka: mereka akan membuat programmer marah. Lihatlah kekuatan umpan balik.)

Perhatikan bahwa Anda juga dapat melakukan hal-hal menyenangkan seperti membuat grafik "bilah profil" terus menerus, sehingga Anda dapat melihat pola lonjakan ("kami kehilangan bingkai setiap 7 frame") atau sejenisnya.

Namun, untuk menjawab pertanyaan Anda secara langsung: dalam pengalaman saya, sementara itu menggoda (dan seringkali bermanfaat - saya biasanya belajar sesuatu) untuk menulis ulang fungsi / modul tunggal untuk mengoptimalkan jumlah instruksi atau kinerja icache atau dcache, dan kami benar-benar perlu melakukan ini kadang-kadang ketika kita punya masalah kinerja yang sangat menjengkelkan, sebagian besar masalah kinerja yang kita tangani secara teratur datang ke desain . Sebagai contoh:

• Haruskah kita cache dalam RAM atau memuat ulang dari frame animasi "serangan" negara untuk pemain? Bagaimana dengan setiap musuh? Kami tidak memiliki RAM untuk melakukan semuanya, tetapi beban disk mahal! Anda dapat melihat halangan jika 5 atau 6 musuh yang berbeda muncul sekaligus! (Oke, bagaimana dengan pemijahan yang mengejutkan?)
• Apakah kita melakukan satu jenis operasi di semua partikel, atau semua operasi di satu partikel? (Ini adalah tradeoff icache / dcache, dan jawabannya tidak selalu jelas.) Bagaimana kalau memisahkan semua partikel dan menyimpan posisi bersama-sama ("struct of arrays" yang terkenal)) vs. menjaga semua data partikel di satu tempat (" array struct ").

Anda mendengarnya sampai menjadi menjengkelkan di setiap program ilmu komputer tingkat universitas, tetapi: itu benar-benar tentang struktur data dan algoritma. Menghabiskan waktu pada algoritma dan desain aliran data akan membuat Anda mendapatkan lebih banyak uang secara umum. (Pastikan Anda telah membaca Kesulitan Pemrograman Berorientasi Objek slide rekan Layanan Pengembang Sony untuk beberapa wawasan di sini.) Ini tidak "terasa" seperti optimisasi; sebagian besar waktu dihabiskan dengan papan tulis atau alat UML atau membuat banyak prototipe, daripada membuat kode saat ini berjalan lebih cepat. Tetapi secara umum jauh lebih bermanfaat.

Dan heuristik lain yang bermanfaat: jika Anda dekat dengan "inti" mesin Anda, mungkin perlu upaya dan percobaan ekstra untuk mengoptimalkan (misalnya, vektorkan matriks yang berlipat ganda itu!). Semakin jauh dari inti, semakin sedikit Anda harus khawatir tentang itu kecuali salah satu alat profil Anda memberi tahu Anda sebaliknya.

1. Gunakan struktur data dan algoritma yang tepat di depan.
2. Jangan mengoptimalkan mikro sampai Anda profil dan tahu persis di mana hot spot Anda.
3. Jangan khawatir tentang menjadi pintar. Kompiler sudah melakukan semua trik kecil yang Anda pikirkan ("Oh! Saya perlu mengalikan empat! Saya akan bergeser ke kiri dua!")
4. Perhatikan kesalahan cache.

Namun ingat juga "pesimisasi dini". Meskipun tidak perlu melakukan hardcore pada setiap baris kode, ada justifikasi untuk menyadari bahwa Anda benar-benar bekerja pada sebuah game, yang memiliki implikasi kinerja waktu-nyata.
Meskipun semua orang memberi tahu Anda untuk mengukur dan mengoptimalkan hot-spot, teknik itu tidak akan menunjukkan kepada Anda kinerja yang hilang di tempat tersembunyi. Misalnya, jika setiap operasi '+' dalam kode Anda akan memakan waktu dua kali lebih lama dari yang seharusnya, itu tidak akan muncul sebagai hot-spot dan dengan demikian Anda tidak akan pernah mengoptimalkannya atau bahkan menyadarinya, namun karena ini digunakan di luar tempat itu mungkin dikenakan biaya banyak kinerja. Anda akan terkejut betapa banyak dari siklus itu mengalir keluar tanpa pernah terdeteksi. Jadi sadarilah apa yang Anda lakukan.
Terlepas dari itu, saya cenderung membuat profil secara teratur untuk mendapatkan ide tentang apa yang ada di sana, dan berapa banyak waktu yang tersisa per frame. Bagi saya waktu per frame adalah yang paling logis karena ia memberitahu saya secara langsung di mana saya berada dengan tujuan framerate. Juga coba cari tahu di mana puncaknya dan apa yang menyebabkannya - Saya lebih suka framerate stabil daripada framerate tinggi dengan paku.

Setelah gim siap dirilis (baik final atau beta), atau terasa lambat, itu mungkin waktu terbaik untuk membuat profil aplikasi Anda. Tentu saja, Anda selalu dapat menjalankan profiler di titik mana pun; tapi ya, optimasi prematur adalah akar dari semua kejahatan. Optimasi tanpa dasar juga; Anda memerlukan data aktual untuk menunjukkan bahwa beberapa kode lambat, sebelum Anda harus mencoba "mengoptimalkannya". Profiler melakukan itu untuk Anda.

Jika Anda tidak tahu tentang profiler, pelajari itu! Berikut adalah posting blog yang bagus yang menunjukkan kegunaan profiler.

Sebagian besar pengoptimalan kode permainan diturunkan untuk mengurangi siklus CPU yang Anda butuhkan untuk setiap frame. Salah satu cara untuk melakukan ini adalah hanya mengoptimalkan setiap rutin saat Anda menulisnya, dan pastikan itu secepat mungkin. Namun, ada pepatah umum bahwa 90% dari siklus CPU dihabiskan dalam 10% dari kode. Ini berarti bahwa mengarahkan semua pekerjaan optimasi Anda ke rutinitas bottleneck ini akan memiliki 10x efek mengoptimalkan semuanya secara seragam. Jadi bagaimana Anda mengidentifikasi rutinitas ini? Pembuatan profil memudahkan.

Jika tidak, jika gim kecil Anda berjalan pada 200 FPS meskipun memiliki algoritma yang tidak efisien, apakah Anda benar-benar memiliki alasan untuk mengoptimalkan? Anda harus memiliki gagasan yang baik tentang spesifikasi mesin target Anda, dan pastikan gim tersebut berjalan dengan baik pada mesin itu, tetapi apa pun di luar itu (bisa dibilang) terbuang waktu yang bisa lebih baik dihabiskan untuk coding atau memoles gim.

Saya merasa bermanfaat untuk membangun profil. Bahkan jika Anda tidak secara optimal mengoptimalkannya, ada baiknya untuk mengetahui apa yang membatasi kinerja Anda pada waktu tertentu. Banyak game memiliki semacam HUD overlay yang menampilkan grafik grafik sederhana (biasanya hanya bar berwarna) yang menunjukkan berapa lama berbagai bagian dari loop game mengambil setiap frame.

Ini akan menjadi ide yang buruk untuk meninggalkan analisis kinerja dan optimasi terlambat pada tahap akhir. Jika Anda sudah membuat game dan Anda 200% di atas anggaran CPU Anda dan Anda tidak dapat menemukannya melalui optimasi, Anda kacau.

Anda perlu tahu apa anggaran untuk grafik, fisika, dll, saat Anda menulis. Anda tidak dapat melakukan itu jika Anda tidak tahu apa yang akan terjadi dengan kinerja Anda, dan Anda tidak dapat menebaknya tanpa mengetahui apa kinerja Anda, dan berapa banyak kelonggaran di sana.

Jadi, buatlah beberapa statistik kinerja sejak hari pertama.

Mengenai kapan menangani masalah - lagi, mungkin lebih baik jangan sampai terlambat, jangan sampai Anda harus memperbaiki setengah mesin Anda. Di sisi lain, jangan terlalu sibuk dengan hal-hal mengoptimalkan untuk memeras setiap siklus jika Anda berpikir Anda mungkin mengubah algoritma sepenuhnya besok, atau jika Anda belum memasukkan data game nyata melalui itu.

Angkat buah rendah tergantung saat Anda pergi, menangani hal-hal besar secara berkala, dan Anda harus baik-baik saja.

Jika melihat kutipan Knuth dalam konteksnya ia melanjutkan dengan menjelaskan, bahwa kita harus mengoptimalkan tetapi dengan alat, seperti profiler.

Anda harus terus-menerus membuat profil dan memori profil aplikasi Anda setelah arsitektur yang sangat dasar diletakkan.

Profiling tidak hanya akan membantu Anda meningkatkan kecepatan, itu akan membantu Anda menemukan bug. Jika program Anda tiba-tiba mengubah kecepatan secara drastis, ini biasanya karena bug. Jika Anda tidak membuat profil, mungkin tidak diketahui.

Trik untuk mengoptimalkan adalah melakukannya dengan desain. Jangan tunggu sampai menit terakhir. Pastikan desain program Anda memberi Anda kinerja yang Anda butuhkan tanpa benar-benar pada trik lingkaran dalam yang jahat.

Untuk proyek saya, saya biasanya menerapkan beberapa optimasi SANGAT dibutuhkan di mesin dasar saya. Sebagai contoh, saya selalu ingin mengimplementasikan implementasi SIMD padat yang baik menggunakan SSE2 dan 3DNow! Ini memastikan matematika titik apung saya sesuai dengan yang saya inginkan. Praktik baik lainnya adalah membuat kebiasaan dari optimisasi saat Anda membuat kode alih-alih kembali. Sebagian besar waktu praktik-praktik kecil ini sama memakan waktu dengan apa yang Anda coding. Sebelum membuat kode fitur, pastikan Anda meneliti cara paling efisien untuk melakukannya.

Intinya, menurut saya, KERAS untuk membuat kode Anda lebih efisien setelah sudah payah.

Saya akan mengatakan bahwa cara termudah adalah menggunakan akal sehat Anda - jika sesuatu terlihat berjalan lambat, maka lihatlah. Lihat apakah itu hambatan.
Gunakan profiler untuk melihat fungsi kecepatan yang diambil dan seberapa sering mereka dipanggil.
Sama sekali tidak ada gunanya mengoptimalkan atau menghabiskan waktu mencoba mengoptimalkan sesuatu yang tidak membutuhkannya.

Jika kode Anda berjalan lambat, kemudian jalankan profiler dan lihat apa yang menyebabkannya berjalan lebih lambat. Atau Anda bisa proaktif dan sudah membuat profiler berjalan sebelum Anda mulai melihat masalah kinerja.

Anda akan ingin mengoptimalkan ketika framerate Anda turun ke titik di mana permainan mulai menderita. Pelakunya yang paling mungkin adalah CPU Anda terlalu banyak digunakan (100%).

Anda harus mengoptimalkan kode Anda ... sesering yang Anda butuhkan.

Apa yang telah saya lakukan di masa lalu hanya terus menjalankan permainan dengan profil diaktifkan (setidaknya konter framerate di layar setiap saat). Jika permainan semakin lambat (di bawah target framerate Anda di mesin min spec, misalnya), nyalakan profiler dan lihat apakah ada hot spot muncul.

Terkadang bukan kodenya. Banyak masalah yang saya alami di masa lalu berorientasi pada GPU (memang, ini ada di iPhone). Isi masalah, terlalu banyak panggilan, tidak cukup geometri, shader tidak efisien ...

Selain algoritma yang tidak efisien untuk masalah-masalah yang sulit (yaitu merintis jalan, fisika), saya sudah sangat jarang mengalami masalah di mana kode itu sendiri adalah biang keladinya. Dan masalah-masalah sulit itu haruslah hal-hal yang Anda habiskan banyak upaya Anda untuk mendapatkan algoritma yang benar dan tidak khawatir tentang hal-hal kecil.

Bagi saya adalah yang terbaik ikuti model data yang dipersiapkan dengan baik. Dan optimalisasi-sebelum langkah utama ke depan. Maksud saya sebelum mulai menerapkan sesuatu yang baru. Alasan lain untuk optimalisasi adalah ketika saya kehilangan kontrol pada sumber daya, App membutuhkan banyak beban CPU / beban GPU atau memori dan saya tidak tahu mengapa :) atau terlalu banyak.