Membina periode waktu di mana setiap orang dapat mencoba ide apa pun untuk membuat perangkat lunak berjalan lebih cepat?

Kadang-kadang trik kinerja perangkat lunak ditemukan dari pencarian metodologis dan menyeluruh. Terkadang dibutuhkan pemikiran yang berbeda dan keberanian untuk mencoba ide-ide gila. Terkadang sebuah ide hanyalah permulaan yang perlu diikuti dengan banyak kerja keras.

Bagaimana mengembangkan periode waktu di mana setiap orang dapat mencoba berbagai ide untuk meningkatkan kinerja perangkat lunak yang sedang kami kerjakan? Setiap orang di tim memiliki setidaknya beberapa bulan pengalaman dengan perangkat lunak dan sangat baik dalam hal itu.

Apakah Anda setuju bahwa pemikiran yang berbeda akan membantu menemukan cara untuk meningkatkan kinerja perangkat lunak? Mengapa? Kenapa tidak?

Teknik apa yang memungkinkan kami untuk dengan cepat mencoba ide pengoptimalan? Apakah kecepatan pengkodean cepat diperlukan untuk mendapatkan hasil yang baik dari uji coba?

Akhirnya, berapa banyak "waktu" yang harus dialokasikan untuk memastikan hasil yang baik tanpa menciptakan kemungkinan mengendur?

Apakah eksperimen diperlukan untuk membuktikan bahwa "cara yang lebih cepat untuk melakukan sesuatu" ada? (Ditambahkan 2011-06-07)

Terkait:

• Apa strategi Anda untuk meningkatkan level tim Anda dengan cara yang cerdas?
• Kapan peretasan kode menjadi buruk?

(Hanya untuk tujuan karunia -2011/06/07 ukuran tim adalah 2-4 pengembang, tidak ada QA khusus. Semua kode, uji unit dan uji kinerja yang dilakukan oleh pengembang. Karena sifat proyek, hasil profiler berguna dalam menunjukkan waktu eksekusi proporsional bahkan jika itu tidak mengungkapkan hambatan tunggal.)

Taruhan terbaik Anda adalah mengidentifikasi hotspot dengan profiler dan - sebagai tim - mendiskusikan cara memperbaiki hotspot.

Anda harus dapat mengukur dan mendokumentasikan peningkatan (jadi itu bukan hanya tebakan liar) dan melakukannya sebagai tim memastikan bahwa orang tahu apa yang sedang diperbaiki dan bagaimana caranya.

Memiliki programmer yang meretas basis kode untuk mencoba ide berarti Anda tidak memiliki kendali atas apa yang sedang terjadi, dan apakah itu berfungsi.

Programmer cenderung pintar dan kreatif (karena ini merupakan prasyarat untuk menjadi pemrograman yang baik) sehingga selalu baik untuk membiarkan mereka mencoba berbagai ide ketika mencoba menyelesaikan masalah. Namun ada dua hal yang penting untuk diingat ketika mencoba meningkatkan kinerja (saya berasumsi dengan "kinerja" yang Anda maksudkan mengurangi kecepatan eksekusi):

• Optimalisasi algoritma cenderung bekerja jauh lebih baik daripada yang lain. Sebagai contoh sepele, apa pun yang Anda lakukan untuk implementasi bubblesort Anda, dengan jumlah yang cukup implementasi quicksort yang sangat lambat pada akhirnya akan lebih cepat.
• Melakukan sesuatu yang berhubungan dengan kinerja sama sekali tidak masuk akal kecuali Anda mengukur (profil) dan mendasarkan apa pun yang Anda lakukan pada hasilnya.

Poin utama saya adalah bahwa penting untuk memastikan Anda berada di halaman yang sama dengan semua orang mengenai hal-hal ini sebelum Anda memulai periode eksperimen liar . Sangat memalukan untuk mengetahui setelah itu bahwa rekan kerja Anda yang kurang berpengalaman mencoba hal-hal yang tidak akan pernah berhasil (dan Anda bisa mengatakannya di depan).

Sayangnya, saya tidak dapat berbicara dari pengalaman. Tetapi saya mendengar bahwa Atlassian memiliki satu hari di mana karyawan diizinkan untuk melakukan hal mereka sendiri, apa pun yang mereka inginkan, dan mempresentasikan ide-ide mereka dalam semacam suasana pesta. Ternyata ternyata baik untuk mereka. Tapi saya harus setuju dengan Andersen dan mengatakan bahwa ketika datang ke kinerja, ide-ide kreatif dan out-of-the-box kurang penting daripada membuat profil proses apa yang paling memakan waktu. Mungkin setelah Anda membuat profil sistem Anda, Anda dapat memberi setiap hari satu hari untuk menghasilkan ide-ide tentang bagaimana membantu mempercepat bagian-bagian penting dari proses tersebut. Setelah mereka mempresentasikan ide-ide mereka, Anda dapat memilih mana yang akan dicoba.

Salah satu latihan sukses yang kami lakukan pada beberapa tim saya sebelumnya adalah memiliki konsep Deep Dives. Beberapa orang akan berkumpul di ruang konferensi, menentukan beberapa skenario pengguna, dan baru mulai melangkah melalui kode atau melihat log profiler. Dalam beberapa kasus, data jelas menunjukkan kemacetan yang memungkinkan kami untuk meyakinkan para skeptis bahwa memang ada masalah kinerja dalam kode mereka sendiri! Untuk membuat ini berhasil, ada beberapa prinsip utama yang kami ikuti:

1. Cobalah untuk fokus pada skenario kritis atau jalur kode di mana kemacetan diduga. Jangan buang waktu untuk mengoptimalkan hal-hal yang tidak perlu dioptimalkan (jika tidak rusak ...)
2. Buat grup tetap kecil dan fokus pada orang-orang yang paling tahu kode. Jangan lupa untuk menyertakan penguji dan pengelola program dari fitur - mereka memiliki wawasan kunci dan dapat mengambil manfaat dari berpartisipasi, atau mengumpulkan info tentang cara mereka dapat menguji lebih baik.
3. Mulailah sesi dengan meminta pemilik area memberikan diagram level blok arsitektur tingkat tinggi dan tinjauan umum area tersebut. Apa saja komponen kunci dan jelaskan secara singkat apa yang mereka lakukan. Anda akan terkejut berapa kali diagram blok tidak mencerminkan kenyataan begitu kita menggali ke dalam kode. (Kutipan aktual: "Saya tidak tahu kami masih menggunakan komponen itu. Saya pikir kami sudah menyingkirkannya bertahun-tahun yang lalu!")
4. Berharap untuk menemukan bug fungsional serta masalah kinerja. Itu hal yang baik. Juga, berharap itu, kadang-kadang, Anda tidak akan menemukan sesuatu yang signifikan. Itu bisa menjadi hal yang baik juga.
5. Berharap untuk memiliki beberapa sesi panjang. Ini adalah rapat kerja. Dapatkan nyaman, dan bekerja melaluinya. Anda mendapatkan lebih banyak pekerjaan ketika Anda semua bisa berkolaborasi untuk peregangan yang panjang.
6. Buat catatan, catatan bagus. Jika Anda menggunakan basis data pelacakan cacat, pertimbangkan untuk segera membuka masalah untuk melacak, meskipun prioritasnya rendah.

Hindari agar seluruh tim berpartisipasi dalam "Dorongan Kinerja." Ini biasanya tidak memiliki hasil yang manajemen harapkan karena alasan yang disebutkan oleh Thorbjørn Ravn Andersen dalam jawaban lain. Anda akan mendapatkan keuntungan besar di beberapa area, regresi di area lain di mana orang tidak terbiasa, dan sulit untuk memprediksi / melacak berapa banyak keuntungan yang harus Anda dapatkan untuk mengatakan "Anda selesai." Itu percakapan yang menantang untuk dimiliki dengan manajemen.

Alasan mengapa Anda mungkin perlu meningkatkan kecepatan perangkat lunak Anda adalah jika sesuatu di dalamnya terasa lambat. Jika itu tidak terjadi, maka mengoptimalkan adalah buang-buang waktu. Tetapi jika ada sesuatu yang lambat, maka lakukan tugas itu.

... Dan untuk melakukan tugas itu, ada dua langkah dalam urutan ini:

1. Lihat apakah fungsi yang melakukan tugas ditulis secara efisien. Apakah ada algoritma yang baik atau buruk? Apakah mengakses database dengan cara yang efisien. Apakah ini berulang 100 kali ketika satu kali bisa dilakukan? Seringkali, pemeriksaan sederhana terhadap kode dapat menemukan satu kendala dan tidak hanya memperbaikinya, tetapi juga menjadikan Anda seorang programmer yang lebih baik secara bersamaan.

2. Jangan menghabiskan lebih dari satu jam atau lebih pada nomor 1. Jika Anda tidak dapat menemukan masalah dalam satu jam, kemudian gunakan profiler untuk menemukan tempat yang dimaksud. Setelah Anda mengetahui titik masalahnya, Anda dapat kembali ke nomor 1 dan melakukannya lagi, sambil mencari cara terbaik untuk meningkatkan kode yang telah Anda identifikasi.

Secara umum (**) Anda tidak mendapatkan kinerja yang lebih baik dengan eksperimen.

Anda mendapatkannya

• Mengetahui cara membuat desain yang sederhana dan efisien untuk memulai. Jika Anda salah melakukannya, eksperimen tidak akan membuat banyak perbedaan. Misalnya, tahu bagaimana cara mengetahui kapan menggunakan generator kode adalah pendekatan desain yang unggul.

• Mengetahui cara menyetel perangkat lunak dengan mencari kegiatan yang a) mahal berdasarkan persentase, dan b) dapat diganti dengan sesuatu yang lebih baik. Semua orang tahu Anda harus "menggunakan profiler", tetapi itu tidak cukup.

Periksa jawaban ini untuk pertanyaan Anda yang lain.

** Pengecualian mungkin berupa kode yang bergantung pada perangkat keras, seperti rendering grafik, pipa prosesor atau perilaku CUDA, atau bereksperimen dengan protokol jaringan atau DB, di mana Anda hanya perlu membiasakan diri dengan cara terbaik untuk menggunakannya.

TAMBAH: Ada sesuatu yang mengejutkan banyak programmer dari sistem besar. Itu adalah bahwa dalam program besar yang dibangun dengan sangat baik, mungkin ada masalah kinerja yang besar dan tidak terlihat , dan pembuat profil tidak dapat menemukannya karena mereka tidak dilokalisasi ke rutinitas. Mereka adalah bagian dari struktur umum program, meskipun program dapat dilakukan dengan gaya terbaik.

Sebagai contoh nyata, berikut adalah program dengan kode sumber (dalam C ++) yang berfungsi. Itu disaring dari program C nyata yang saya kerjakan.

Itu tidak apa itu dimaksudkan untuk lakukan, tapi apa sebagian kecil dari waktu yang tidak benar-benar diperlukan? Berapa banyak yang bisa dipercepat?

Nah, dalam versi pertama program, sesuatu yang tampak masuk akal dan nonlokal (tidak terlihat oleh profiler) mengambil 33,3% dari waktu. Ketika diganti, waktu itu disimpan, dan itu adalah versi kedua dari program.

Dalam versi kedua dari program, sesuatu yang lain (tidak terlihat oleh profiler mana pun) yang dapat dihapus membutuhkan 16,7% dari waktu. Menghapusnya menyebabkan versi 3.

Dalam versi 3, 13% dihapus. Dari apa yang tersisa, 66% telah dihapus. Dari apa yang tersisa setelah itu, 61% telah dihapus!

Kemudian akhirnya, dari apa yang tersisa setelah itu, 98% telah dihapus!

Jadi apa gambaran besarnya? Dari setiap 1000 siklus yang dihabiskan oleh program asli, berapa banyak yang dihapus? 998!

Setiap program berbeda, tetapi setiap program besar, menurut pengalaman saya, memiliki serangkaian masalah waktu yang tidak akan ditemukan oleh profiler, pengambilan sampel manual akan dilakukan, dan bahwa, jika programmer benar - benar mencari kinerja maksimal, dapat dihapus untuk speedup besar.