Mengotomasi Pengujian Kinerja XNA?

Saya bertanya-tanya apa pendekatan atau pemikiran orang tentang mengotomatisasi pengujian kinerja dalam XNA. Saat ini saya melihat hanya bekerja di 2d, tetapi itu menimbulkan banyak bidang di mana kinerja dapat ditingkatkan dengan implementasi yang berbeda.

Contohnya adalah jika Anda memiliki 2 implementasi yang berbeda dari partisi spasial, yang satu mungkin lebih cepat dari yang lain tetapi tanpa melakukan beberapa pengujian kinerja yang sebenarnya Anda tidak akan dapat mengetahui yang mana yang pasti (kecuali jika Anda melihat kode itu sangat lambat secara pasti di tertentu bagian). Anda bisa menulis unit test yang untuk jangka waktu tertentu terus menambah / memperbarui / menghapus entitas untuk kedua implementasi dan melihat berapa banyak yang dibuat dalam setiap jangka waktu dan yang lebih tinggi akan lebih cepat (dalam contoh yang diberikan ini).

Contoh tingkat lebih tinggi lainnya adalah jika Anda ingin melihat berapa banyak entitas yang dapat Anda miliki di layar secara kasar tanpa melebihi 60fps. Masalah dengan ini adalah untuk mengotomatiskannya, Anda perlu menggunakan trik bentuk tersembunyi atau hal lain untuk memulai permainan tiruan dan murni menguji bagian mana yang Anda sayangi dan nonaktifkan yang lainnya.

Saya tahu ini bukan urusan sederhana, bahkan jika Anda dapat mengotomatiskan tes, benar-benar terserah manusia untuk menginterpretasikan jika hasilnya cukup berkinerja, tetapi sebagai bagian dari langkah membangun Anda dapat menjalankan tes ini dan menerbitkannya. hasil di suatu tempat untuk perbandingan.

Dengan cara ini jika Anda beralih dari versi 1.1 ke 1.2 tetapi telah mengubah beberapa algoritma yang mendasari Anda mungkin memperhatikan bahwa secara umum skor kinerja akan naik, yang berarti Anda telah meningkatkan kinerja aplikasi secara keseluruhan, dan kemudian dari 1,2 menjadi 1,3 Anda mungkin memperhatikan Anda kemudian telah menurunkan kinerja keseluruhan sedikit.

Jadi, adakah yang mengotomatiskan hal semacam ini dalam proyek mereka, dan jika demikian, bagaimana Anda mengukur perbandingan kinerja Anda pada tingkat tinggi dan kerangka kerja apa yang Anda gunakan untuk menguji? Karena Anda telah menulis kode Anda sehingga dapat diuji / dapat dipermainkan untuk sebagian besar Anda hanya dapat menggunakan tes Anda sebagai mekanisme untuk mendapatkan beberapa hasil kinerja ...

=== Edit ===

Hanya untuk kejelasan, saya lebih tertarik dengan cara terbaik untuk menggunakan tes otomatis dalam XNA untuk melacak kinerja Anda, tidak bermain pengujian atau menebak dengan menjalankan game Anda secara manual di mesin. Ini benar-benar berbeda dengan melihat apakah game Anda dapat dimainkan pada perangkat keras X, ini lebih tentang melacak perubahan kinerja saat mesin game / kerangka kerja Anda berubah.

Seperti disebutkan dalam salah satu komentar, Anda dapat dengan mudah menguji "berapa banyak node yang dapat saya sisipkan / hapus / perbarui dalam QuadTreeA dalam 2 detik", tetapi Anda harus secara fisik melihat hasil ini setiap kali untuk melihat apakah telah berubah, yang mungkin baik dan masih lebih baik daripada hanya mengandalkan bermain untuk melihat apakah Anda melihat ada perbedaan antara versi. Namun jika Anda memasukkan Assert untuk memberi tahu Anda tentang kegagalan jika lebih rendah dari katakanlah 5.000 dalam 2 detik Anda memiliki tes rapuh karena kemudian kontekstual ke perangkat keras, bukan hanya implementasi. Meskipun demikian dikatakan tes otomatis semacam ini hanya benar-benar ada gunanya jika Anda menjalankan tes Anda sebagai semacam pipa pembangunan yaitu:

Checkout -> Jalankan Tes Unit -> Jalankan Tes Integrasi -> Jalankan Uji Kinerja -> Paket

Jadi, Anda dapat dengan mudah membandingkan statistik dari satu bangunan ke yang lain di server CI sebagai semacam laporan, dan sekali lagi ini mungkin tidak banyak berarti bagi siapa pun jika Anda tidak terbiasa dengan Integrasi Berkelanjutan. Inti utama dari pertanyaan ini adalah untuk melihat bagaimana orang mengelola ini di antara bangunan dan bagaimana mereka menemukan cara terbaik untuk melaporkannya. Seperti yang saya katakan itu bisa subjektif tetapi karena pengetahuan akan diperoleh dari jawaban itu sepertinya pertanyaan yang berharga.

xna performance testing

— Grofit
sumber

+1 pertanyaan bagus. Saya belum melakukan ini, tetapi perlu segera.

— ashes999

Hanya untuk mengklarifikasi saya tidak benar-benar berbicara tentang profiler atau alat eksternal benar-benar, meskipun itu bisa menjadi hal tambahan untuk membantu mendiagnosis bagian lambat dll. Apa yang saya pikirkan adalah tentang menggunakan unit test Anda untuk memberi Anda beberapa konteks seolah-olah jika Anda juga meningkatkan kinerja, sehingga Anda dapat menerapkan algoritma baru untuk merintis jalan, dan segera mengujinya secara terpisah dengan versi Anda sebelumnya, dan membandingkan angka-angka yang secara instan memberi tahu Anda bahwa Anda telah meningkatkan atau membuang-buang waktu tanpa harus mengintegrasikannya ke dalam proyek utama dan menyebarkannya.

— Grofit

pertanyaan Anda agak membingungkan; Anda sedang berbicara tentang pengukuran kinerja umum, yang dapat dilakukan TANPA tes; tetapi Anda juga dapat menulis tes seperti "tes X terjadi dalam waktu kurang dari 3 detik."

— ashes999

Yap dan bahwa "tes X terjadi dalam waktu kurang dari 3 detik" berada di jalur yang benar, tetapi sebaliknya tes seperti "Berapa banyak node yang bisa saya masukkan ke dalam quad tree dalam 5 detik", hasil yang untuk satu build mungkin adalah 10.000, dan bangunan berikutnya mungkin 5.000. Melihat hal itu dengan segera, Anda dapat membuat keputusan berdasarkan informasi jika Anda telah mengajukan masalah. Masalahnya bagi saya adalah bahwa semua informasi ini baik, tetapi Anda harus melihatnya. Seperti menambahkan pernyataan untuk <7500 dalam waktu mungkin tampak baik-baik saja, tetapi jika Anda menjalankannya pada mesin yang berbeda mungkin tidak lulus, tetapi pada kenyataannya IMPLEMENTASI tidak lebih lambat.

— Grofit

Jawaban:

Saya kira Anda benar-benar ingin mengesampingkan "Jalankan game yang sebenarnya", jadi pada dasarnya jawaban saya didiskualifikasi sejak awal. Tapi mungkin Anda dapat mengambil sesuatu darinya, karenanya saya memposting ini terlepas:

Untuk tesis Master saya, saya memiliki berbagai implementasi independen / paralel untuk mencapai hal yang sama untuk beberapa modul mesin permainan saya dan saya perlu melakukan beberapa pengukuran kinerja. Secara teknis, tidak ada yang akan mencegah saya dari hanya menjalankan permainan dan melihat angka-angka yang ditampilkan di profiler layar, tapi saya masih ingin mengotomatisasi itu karena itu adalah proses yang membosankan untuk melakukan setiap kali implementasi saya berubah.

Jadi yang saya miliki adalah ini:

Profiler scoped (yang menempatkan objek pada stack, membutuhkan cap waktu pada konstruksi dan satu pada dekonstruksi) yang digunakan untuk mengukur berapa lama fungsi / ruang lingkup minat yang diperlukan untuk mengeksekusi
Modul yang menyimpan sejumlah sampel yang diprofilkan dan membuang rata-rata melintasi n sampel terakhir ke file teks sederhana
Baris perintah dalam gim yang dapat digunakan untuk memulai gim, memuat peta, mengubah algoritma yang digunakan dalam modul yang akan diperiksa, mengubah jalur file dump profiler dan banyak hal lainnya. Baris perintah tersebut diatur untuk memeriksa file khusus tertentu dalam direktori yang dapat dieksekusi dan memuatnya untuk mengeksekusi string yang diambil darinya (sebagai sarana komunikasi antar proses yang sangat, sangat kasar)

Jadi apa yang memungkinkan saya lakukan adalah meluncurkan aplikasi saya dari lingkungan scripting yang setengah layak (misalnya, prompt perintah windows melalui skrip batch - tapi saya benar-benar menggunakan Ruby untuk tujuan itu), mengatur jalur file dump, memuat peta, tinggalkan saja berjalan selama beberapa menit, keluar dari game yang sedang berjalan, atur jalur file dump yang lain, alihkan algoritme yang digunakan, muat peta lagi, bilas, ulangi. Script Ruby berkomunikasi dengan game dalam penerbangan dengan membuat file khusus yang dicari oleh modul baris perintah dan meletakkan perintah yang diinginkan dalam sintaks yang dimengerti oleh baris perintah.

Saya tidak benar-benar menggunakan integrasi berkelanjutan pada proyek ini sekarang, tetapi tidak ada yang akan mencegah saya memenuhi naskah Ruby itu untuk juga menguraikan log kinerja yang dihasilkan dan menghasilkan XML yang kompatibel dengan xUnit untuk berkomunikasi dengan sistem CI ketika kinerja tiba-tiba menjadi kacau karena beberapa alasan dan menjalankan script pada setiap build penuh pada build sever.

Baiklah, begitu juga gim saya ditulis dalam XNA (ini jelas C ++ dan DirectX), juga pendekatan ini tidak menghargai kenyataan bahwa Anda tidak benar-benar ingin menjalankan gim tersebut di server build Anda. Ini juga tidak sefleksibel yang mungkin Anda inginkan - tapi tetap saja, ini merupakan pendekatan yang rapi, berteknologi rendah untuk pengukuran kinerja otomatis yang agak ramah-CI (asalkan ada yang memiliki server build gemuk).

Sunting: Adapun sejauh mana saya benar-benar mengambil pendekatan itu - saya hanya membandingkan pengukuran kinerja yang diperoleh dari berbagai implementasi hanya modul yang satu ini. Tetapi seluruh sistem diatur dengan cara yang akan memungkinkan saya untuk membuang salah satu dari kategori yang ditentukan untuk kerangka profiling ringan saya dan menggunakan lingkungan skrip eksternal untuk menafsirkan hasil dengan cara apa pun yang tampaknya berguna di sana dan kemudian. Mengambil aspek profil kinerja dari persamaan, saya lebih lanjut bermaksud

Periksa validitas / konsistensi semua aset dengan memuat semua peta yang berisi semua model / tekstur / suara dan memeriksa log engine untuk hal-hal yang tidak biasa
uji stres mesin dan pantau log untuk setiap perilaku tak terduga yang melintasi rentang waktu beberapa jam / hari

— Koarl
sumber

Semua info bagus, telah memberi Anda +1. Dari suara itu meskipun semua yang Anda lakukan di atas dapat dengan mudah dilakukan dalam semacam tes integrasi. Satu-satunya hal yang perlu Anda khawatirkan adalah mengejek game / simulasi yang sebenarnya. Ketika Anda tepat dengan membuat komponen mesin / kerangka kerja Anda terisolasi sehingga mereka dapat diuji dalam konteks mereka sendiri, di situlah saya mencoba untuk mendapatkan. Karena saya tidak ingin menguji kinerja permainan saya karena itu adalah binatang yang selalu berubah, kerangka kerjanya jarang berubah dan dapat dengan mudah diatur untuk menjalankan sejumlah skenario seperti yang Anda sebutkan.

— Grofit

Terima kasih. Seperti yang ditunjukkan oleh hal-hal yang ingin saya capai di masa depan, saya bertujuan untuk mengotomatisasi hal-hal yang terjadi dalam permainan nyata - Hasilnya kebetulan cukup nyaman untuk pengukuran kinerja juga.

— Koarl

Saya tidak melihat apa yang Anda gambarkan sebagai alat yang bermanfaat. Sebagai pengembang, angka kinerja sederhana hampir tidak berguna.

Yang Anda inginkan adalah membuat profil kode Anda, membaginya menjadi potongan-potongan logis dan mengukur berapa banyak waktu masing-masing yang digunakan, puncak dan rata-rata. Sekarang Anda dapat mengetahui bagian mana dari kode yang menyebabkan masalah, dan Anda tahu di mana harus mencari optimasi.

Bagian yang sulit bukanlah perubahan kinerja dari satu build ke yang lain, Anda tidak perlu otomatis untuk mengetahuinya. Bagian yang sulit adalah perbedaan kinerja antara mesin yang berbeda, tidak ada cara untuk memperkirakan kinerja dari satu mesin ke komputer lain dengan kartu video yang berbeda dll.

Jadi yang Anda inginkan adalah fitur patokan sehingga Anda dapat melakukan satu klik lari dan mendapatkan nomor profil. Dengan cara ini Anda dapat menguji beberapa mesin secara bersamaan. Ada beberapa cara untuk melakukan ini, misalnya Anda dapat mengganti input pengguna untuk sedekat mungkin dengan menjalankan sesi permainan normal.

Anda mungkin juga ingin melakukan tes yang lebih lama untuk menemukan kebocoran memori.

— aaaaaaaaaaaa
sumber

Jika Anda mengikuti pendekatan gaya CI biasa, di mana Anda menjalankan perangkat lunak Anda melalui server build Anda akan selalu menguji pada mesin yang sama sehingga selalu perangkat keras yang sama, yang memberi Anda dasar untuk angka-angka Anda. Karena itu adalah arah dari mana aku berasal. Anda mengatakan bahwa Anda tidak memerlukan alat untuk mengetahui perubahan kinerja di antara build, yang memang benar Anda dapat menjalankannya sendiri dan melihat perbedaannya, tetapi akan lebih baik jika sistem build atau komputer Anda saat ini dapat memberi Anda angka-angka itu tanpa Anda memiliki untuk melakukan apa pun selain menjalankan tes.

— Grofit

Jika Anda tidak terlalu serius tentang pengujian, Anda memerlukan beberapa mesin uji yang berbeda. Bagaimanapun, apa masalah sebenarnya? Apakah Anda tidak yakin bagaimana kode tolok ukur ke dalam game?

— aaaaaaaaaaaa

Tidak ada masalah seperti itu, saya hanya mencoba untuk mendapatkan beberapa informasi tentang bagaimana beberapa orang telah menerapkan ini pada proyek mereka. Saya tidak berpikir memiliki mesin yang terpisah membantu dengan cara apa pun, karena Anda tidak benar-benar menguji untuk melihat apakah itu berjalan pada 30fps pada perangkat keras rendah dan 60fps pada perangkat keras cepat. Anda mengeluarkan perangkat keras dari persamaan dan dengan tepat melihat mesin / kode sumber Anda. Seperti seharusnya tidak masalah jika Anda menguji pada 486 atau quad core, karena Anda menguji satu build terhadap yang lain, bukan satu set perangkat keras lagi yang lain.

— Grofit

Saya harus setuju sedikit dengan Grofit dan eBusiness untuk yang satu ini. Tes otomatis penting, terutama pada proyek-proyek besar, sehingga ketika membangun apa pun Anda akan tahu jika ada sesuatu yang melukai atau membantu kinerja, dan ini idealnya dilakukan pada satu mesin. Dengan game PC setidaknya Anda juga perlu menguji berbagai jenis perangkat keras, tes otomatis Anda mungkin mengatakan kinerjanya bagus, tetapi kemudian Anda menjalankan game Anda pada GPU lama atau mendapati diri Anda berlari ke dalam memori virtual dan tiba-tiba tangki kinerja Anda. Anda harus dapat menguji hal-hal itu sebelum mereka sampai ke tangan pelanggan.

— Nic Foster

@ Keuntungan Masalahnya adalah, mungkin hanya mesin lama yang merusak build. Ini tidak biasa bahwa perubahan tidak memiliki efek kinerja yang signifikan pada komputer baru, atau bahkan perbaikan, sementara perubahan yang sama sepenuhnya mencegah permainan berjalan di komputer lama. Anda tidak dapat mengeluarkan perangkat keras dari persamaan, tidak ada kinerja kode yang terisolasi. Tetapi jika Anda ingin mengatur uji coba otomatis pada hanya satu mesin, setidaknya lakukan pada junker lama, yang akan memberi Anda kesempatan yang lebih baik dari kegagalan tes.

— aaaaaaaaaaaa