Cara memastikan kinerja mesin status Qt terbaik

Jika Anda menggunakan Qt untuk pengembangan aplikasi dan jika Anda menggunakan mesin status, kemungkinan besar Anda menggunakan kerangka kerja mesin status Qt. Jadi, Anda akan menentukan mesin status menggunakan C++ atau SCXML biasa. Pendekatan alternatif adalah menghasilkan kode C++ dari diagram state machine. Artikel ini membandingkan pendekatan ini, dengan mempertimbangkan fungsionalitas, penerapan, dan kinerja.

Saya yakin bahwa sebagai pengembang perangkat lunak, Anda telah menerapkan banyak pernyataan kasus sakelar yang kurang lebih rumit. Ini paling tidak benar bagi saya, dan banyak dari pengkodean switch-case ini pada dasarnya tidak lain adalah mengimplementasikan mesin negara yang beragam. Ini adalah cara termudah untuk memulai pemrograman state machine jika Anda tidak memiliki apa-apa selain bahasa pemrograman pilihan Anda. Meskipun permulaannya mudah, kode tersebut menjadi semakin tidak dapat dipelihara karena kompleksitas mesin negara meningkat. Pada akhirnya, Anda akan diyakinkan bahwa Anda tidak ingin terus mengimplementasikan mesin negara secara manual dengan cara ini. (Omong-omong – saya berasumsi bahwa Anda tahu apa itu state machine.)

Menerapkan mesin negara

Ada berbagai alternatif untuk mengimplementasikan mesin negara. Salah satu cara yang lebih baik – terutama ketika Anda menggunakan bahasa pemrograman berorientasi objek seperti C++ – adalah dengan menerapkan pola keadaan. Pendekatan ini menggunakan kelas keadaan dan seringkali juga kelas transisi. Mesin status kemudian didefinisikan dengan membuat instance kelas status dan menghubungkannya menggunakan instance kelas transisi. Dalam hal ini, kerangka kerja sangat membantu untuk mengurangi ukuran kode dan upaya implementasi.

Kerangka kerja mesin negara Qt adalah contoh yang baik. API ini memungkinkan Anda untuk "mengonfigurasi" mesin status menggunakan kode ringkas. Anda tidak perlu peduli dengan detail semantik eksekusi mesin status, karena ini sudah diterapkan oleh kerangka kerja. Anda masih harus menulis kode, dan karena mesin status Anda menjadi lebih kompleks dan berisi beberapa lusin atau bahkan ratusan status, akan menjadi sangat sulit untuk mendapatkan gambaran umum. Sebuah gambar bernilai seribu kata, dan konsep diagram keadaan yang terkenal membantu mengatasi kendala ini. Qt sendiri menyediakan dukungan untuk State Chart XML (SCXML), yang merupakan standar W3C. Karena menulis XML dengan tangan tidak menyenangkan,Qt Creator juga menyertakan editor grafik status grafik sederhana.

Terlepas dari pendekatan implementasi konkret, menggunakan sintaks grafis adalah pilihan terbaik untuk mengedit dan memahami mesin keadaan. Model grafis seperti itu tidak hanya dapat diwakili secara tekstual oleh bahasa seperti SCXML tetapi juga dapat digunakan untuk menghasilkan segala jenis kode sumber bahasa pemrograman, seperti mesin status berbasis kasus-switch dalam kode C++ – atau C++ biasa yang menyiapkan instance QStateMachine. Menggunakan alat yang melakukan transformasi seperti itu untuk Anda, Anda dapat menghindari kerumitan kode mesin status tulisan tangan. Ini mengangkat ketiga pendekatan implementasi ke tingkat kegunaan yang sama. Meskipun demikian, implementasinya pada dasarnya masih berbeda. Artikel ini tentang membandingkan perilaku runtime mereka dan terutama performanya.

UnsplashFoto oleh Austris Augusts di Unsplash

Pesaing

Lalu bagaimana dengan kinerja? Bagaimana pendekatan yang tersedia berbeda mengenai siklus CPU yang diperlukan? Untuk mendapatkan beberapa angka konkret, saya menyiapkan rangkaian uji kinerja. Bagian pertama membandingkan strategi implementasi yang berbeda. Ini dia para pesaingnya:

1. Penerjemah SCXML – mesin status pengujian ditentukan menggunakan SCXML dan dijalankan oleh QSCXMLStateMachine Qt kelas.
2. Pola status – mesin status uji diimplementasikan menggunakan QStateMachine kelas.
3. Kode C++ biasa – mesin status pengujian diimplementasikan oleh kelas C++ yang menerapkan pendekatan berbasis kasus sakelar dasar.

Catatan:Kode untuk contoh ini dapat ditemukan di sini.

Dua varian pertama menyiratkan penggunaan konsep Qt seperti sinyal dan slot serta penggunaan antrian acara Qt, sementara implementasi C++ biasa tidak memerlukan infrastruktur ini. Untuk membuat pendekatan lebih sebanding, rangkaian pengujian menyertakan dua skenario pengujian lagi:

• Kode C++ biasa dengan sinyal dan slot – mesin status pengujian memiliki implementasi yang sama seperti yang dijelaskan di atas tetapi menggunakan sinyal dan slot untuk mengintegrasikannya ke dalam aplikasi.
• Kode C++ biasa dengan QEvent – menggunakan pendekatan kode C++ biasa tetapi memanfaatkan antrian acara Qt untuk memproses di dan keluar acara.

Hal ini memungkinkan untuk membandingkan dampak penggunaan sinyal dan slot di satu sisi dan penggunaan QEvents di sisi lain dibandingkan dengan implementasi C++ biasa, karena kode eksekusi mesin keadaan identik dalam semua kasus, tetapi hanya dibungkus secara berbeda.

Mesin status pengujian

Untuk menguji kelima pesaing, saya mendefinisikan mesin status yang ditunjukkan pada gambar. 1 untuk skenario pengujian dasar.

Gambar 1:Mesin status pengujian, seperti yang dibuat dengan Alat Statechart YAKINDU. (Sumber:Penulis)

Mesin keadaan uji adalah mesin keadaan datar sederhana. Ini mendefinisikan enam status A ke B dan siklus melalui negara bagian. Dua peristiwa masukan e1 dan e2 didefinisikan, yang secara bergantian memicu transisi status. Ketika transisi keadaan terjadi, juga tindakan sederhana dijalankan. Setiap tindakan transisi hanya menambahkan 10 ke variabel statechart bernama x . Transisi dari status F ke A tambahan meningkatkan (atau memancarkan) keluar acara o .

Gambar 2:Mesin status pengujian sebagai model SCXML di Qt Creator. (Sumber:Penulis)

State machine ini didefinisikan menggunakan YAKINDU Statechart Tools, yang mendukung pembuatan SCXML. SCXML ini dapat ditambahkan ke proyek Qt dan dapat diedit di Qt Creator. Seperti yang Anda lihat pada gambar. 2, mesin negara memiliki struktur yang identik dengan yang ada di gambar. 1, tetapi beberapa detail, seperti tindakan transisi, tidak terlihat di Qt Creator. YAKINDU Statechart Tools memberikan beberapa keuntungan lagi, tetapi saya tidak akan membahasnya di sini.

Yang lebih penting di sini adalah fakta bahwa YAKINDU Statechart Tools juga dapat menghasilkan kelas mesin status C++ berbasis switch-case biasa. Ini juga menyediakan opsi untuk menghasilkan kelas yang mendukung Qt dengan sinyal dan slot, jadi ini sangat berguna. Dengan menggunakan alat ini, saya hanya perlu mengimplementasikan mesin status berbasis pola negara menggunakan QStateMachine dengan tangan. Tidak ada pembuat kode yang tersedia untuk varian itu. Namun demikian, saya dapat menghemat banyak upaya implementasi, sambil mendapatkan mesin status yang setara secara semantik untuk pengujian kinerja hanya dengan menggunakan definisi diagram status tunggal.

Semua kasus uji mengikuti skema yang sama. Karena saya ingin mengukur waktu rata-rata yang diperlukan untuk memproses peristiwa individual, setiap pengujian menangkap satu juta iterasi dari satu loop keadaan. Setiap loop keadaan melakukan semua peristiwa yang diperlukan untuk mengunjungi semua keadaan dan memproses semua transisi dan tindakan transisi. Jadi, state loop dimulai dan diakhiri dengan state A menjadi aktif. Ini berarti bahwa untuk setiap kasus uji 6 juta di peristiwa dan tindakan transisi dan 1 juta keluar peristiwa dengan tindakan transisi terkaitnya diproses. Pengujian dijalankan sebagai aplikasi baris perintah dan mencatat waktu untuk iterasi sebagai satu batch. Konsumsi waktu per peristiwa kemudian dapat ditentukan dengan sederhana dengan membagi waktu terukur dengan jumlah jumlah dalam acara dan keluar acara. Pengujian dilakukan beberapa kali dan hasil pengukuran dengan nilai terendah dipilih.

Pengujian dilakukan menggunakan kode yang dioptimalkan tanpa informasi debug pada MacBook Pro lama saya (pertengahan 2014), dengan CPU Core i7 Quad Core 2.4GHz. Tentu saja, angka konkret akan berbeda pada mesin dan sistem operasi yang berbeda. Namun, ini tidak relevan, karena saya ingin membandingkan pendekatan implementasi yang berbeda satu sama lain. Perbedaan relatif ini akan sebanding pada perangkat keras dan platform OS yang berbeda.

Mari kita lihat angka kinerjanya

Ya – Saya pikir hampir semua orang mengharapkan implementasi C++ biasa lebih cepat daripada alternatif lain, tetapi besarnya perbedaannya sangat mencengangkan.

Gambar 3:Waktu pemrosesan peristiwa tunggal dibandingkan. (Sumber:Penulis)

Pemrosesan peristiwa tunggal menggunakan C++ biasa membutuhkan waktu rata-rata 7 nanodetik. Menggunakan SCXML membutuhkan 33.850 nanodetik – itu adalah faktor sekitar 4800 dan perbedaan yang sangat besar! Sebagai perbandingan, cahaya menempuh jarak lebih dari 10 kilometer sementara mesin status SCXML hanya memproses satu transisi, sedangkan transisi yang sama dalam mesin status C++ biasa hanya menyisakan begitu banyak waktu bagi cahaya untuk menempuh jarak lebih dari 2 meter. Ini menyiratkan urutan besaran yang sangat berbeda untuk siklus CPU dan konsumsi energi.

Tentu saja angka beton tergantung pada mesin dan prosedur pengujian yang digunakan. Saya akan membahas topik ini nanti. Tapi mari kita bahas nomor lainnya dulu. Tiga skenario pengujian pertama semuanya menyertakan logika transisi status yang identik, yang dihasilkan oleh YAKINDU Statechart Tools, tetapi masing-masing dibungkus dengan cara yang berbeda.

Menggunakan sinyal dan slot untuk menangani peristiwa membutuhkan waktu rata-rata 72 detik saat menggunakan koneksi langsung. Jadi mekanisme ini membebankan overhead minimum ~90%, dibandingkan dengan logika mesin keadaan sebenarnya. Pada titik ini, saya tidak ingin berargumen bahwa menggunakan sinyal dan slot membuat aplikasi menjadi lambat. Alih-alih, saya lebih suka mengklaim bahwa implementasi kode biasa dari mesin negara sangat cepat .

Membandingkan ini dengan skenario ketiga memberikan kesan yang baik tentang overhead kinerja yang disebabkan oleh penggunaan antrian acara. Dalam skenario ini, semua peristiwa statechart dirutekan melalui antrian peristiwa. Dengan 731ns per peristiwa, dibutuhkan faktor ~10 dibandingkan dengan sinyal dan slot dan ~100 dibandingkan dengan C++ biasa.

Kita dapat mengasumsikan bahwa overhead yang sebanding juga berlaku untuk dua skenario lainnya “plain QStateMachine ” dan “SCXML state machine” – keduanya memerlukan antrean peristiwa aktif. Jadi, ketika overhead antrian peristiwa yang diasumsikan dikurangi dari 5200ns per peristiwa, maka kita mendapatkan konsumsi waktu kasar QStateMachine kerangka kerja 4500ns per acara. Dibandingkan dengan pendekatan kode biasa, implementasi state machine berbasis QStateMachine berjalan lambat. Ini adalah faktor sekitar 635, dibandingkan dengan implementasi kode C++ biasa.

Terakhir, mari kita lihat penerjemah SCXML. Ini melibatkan interpretasi kode JavaScript dan menambahkan faktor lain dari ~7. Dibandingkan dengan pendekatan kode biasa, implementasi state machine berbasis SCXML sangat lambat.

Bagaimana dengan mesin status hierarkis dan ortogonal?

Sejauh ini, saya baru saja membuat profil mesin keadaan datar sederhana. Tetapi bagan keadaan menyediakan lebih banyak fitur, dan dua fitur struktural terpenting adalah hierarki dan ortogonalitas. Jadi, apa dampak penggunaan fitur ini terhadap runtime mesin negara?

Pertama, untuk mengukur dampak hierarki, saya mendefinisikan varian hierarkis dari mesin negara yang akan diprofilkan, ditunjukkan pada gambar. 4.

Gambar 4:Diagram status pengujian hierarki. (Sumber:Penulis)

Ini memberikan perilaku yang persis sama dengan mesin keadaan datar, tetapi menambahkan beberapa keadaan komposit. Menjaga fungsionalitas tetap identik, tetapi hanya mengubah struktur, memungkinkan untuk mengetahui berapa banyak overhead yang disiratkan oleh varian struktural, jika ada.

Kedua, untuk mengukur dampak ortogonalitas, saya mereplikasi mesin keadaan datar dalam bentuk empat daerah ortogonal. Mereka semua memiliki fungsi yang persis sama. Jadi, mesin keadaan yang dihasilkan (lihat gbr. 5) akan melakukan empat kali pekerjaan yang dilakukan mesin keadaan sederhana.

Gambar 5:Diagram keadaan uji ortogonal. (Sumber:Penulis)

Untuk pembuatan profil, saya memilih implementasi C++ dan SCXML biasa, karena ini adalah varian tercepat dan paling lambat. Diagram pada gambar. 6 menunjukkan hasilnya. Sangat menggembirakan bahwa menggunakan hierarki dalam bagan status tidak memiliki dampak kinerja yang terukur di kedua varian implementasi.

Gambar 6:Dampak kinerja hierarki dan ortogonalitas. (Sumber:Penulis)

Hasil positif lainnya adalah penggunaan ortogonalitas juga tidak berdampak negatif. Sebaliknya, sementara seseorang mungkin mengharapkan setidaknya empat kali waktu pemrosesan untuk menyelesaikan empat kali pekerjaan, peningkatan efektif dalam runtime dengan faktor ~2.4 dan ~3.1 secara signifikan lebih kecil dari 4.

Mengapa demikian? Alasan untuk ini adalah bahwa ada bagian umum dari pemrosesan mesin keadaan yang tidak tergantung pada pemrosesan keadaan dan kejadian individu. Bagian ini membutuhkan 52% (atau 3,5ns per peristiwa) untuk mesin status C++ biasa, dibandingkan dengan 28% (atau 9300ns per peristiwa) untuk SCXML. Terakhir, status ortogonal memiliki dampak yang lebih kecil saat menggunakan kode C++ yang dihasilkan dibandingkan dengan SCXML.

Kesimpulan

C++ biasa jauh lebih efisien daripada semua alternatif. Menggunakan sinyal dan slot atau antrian peristiwa Qt adalah mekanisme kerangka kerja yang memudahkan penerapan dan pemeliharaan aplikasi state machine yang kompleks. Kerangka kerja mesin status Qt membutuhkan kedua mekanisme ini. Menggunakan kode C++ yang dihasilkan, Anda memiliki pilihan.

Dalam banyak skenario, terutama yang interaktif, bahkan mesin status SCXML cukup cepat, dan mereka dapat memberikan lebih banyak fleksibilitas dengan membuat perilaku dapat dikonfigurasi dengan mengganti definisi diagram status saat runtime.