Biasanya saya benci kata, "optimasi prematur", tetapi ini berbau itu. Perlu dicatat bahwa Knuth menggunakan kutipan terkenal ini dalam konteks mendorong untuk menggunakan goto
pernyataan untuk mempercepat kode di area kritis . Itulah kuncinya: jalur kritis .
Dia menyarankan untuk digunakan goto
untuk mempercepat kode tetapi memperingatkan terhadap para programmer yang ingin melakukan hal-hal semacam ini berdasarkan firasat dan takhayul untuk kode yang bahkan tidak kritis.
Untuk mendukung switch
pernyataan sebanyak mungkin secara seragam di seluruh basis kode (terlepas dari apakah ada beban berat yang ditangani) adalah contoh klasik dari apa yang Knuth sebut sebagai programmer "penny-wise and pound-bodoh" yang menghabiskan sepanjang hari berjuang untuk mempertahankan "dioptimalkan" mereka "kode yang berubah menjadi mimpi buruk debugging sebagai hasil dari mencoba untuk menyimpan uang lebih dari pound. Kode seperti itu jarang dapat dipertahankan apalagi efisien di tempat pertama.
Apakah dia benar
Ia benar dari perspektif efisiensi yang sangat mendasar. Tidak ada kompiler yang setahu saya dapat mengoptimalkan kode polimorfik yang melibatkan objek dan pengiriman dinamis lebih baik daripada pernyataan switch. Anda tidak akan pernah berakhir dengan LUT atau tabel lompat ke kode inline dari kode polimorfik, karena kode seperti itu cenderung berfungsi sebagai penghalang pengoptimal untuk kompiler (ia tidak akan tahu fungsi untuk memanggil hingga waktu pengiriman dinamis terjadi).
Lebih berguna untuk tidak memikirkan biaya ini dalam hal tabel lompatan tetapi lebih dalam hal penghalang optimasi. Untuk polimorfisme, pemanggilan Base.method()
tidak memungkinkan kompiler mengetahui fungsi mana yang sebenarnya akan dipanggil jika method
virtual, tidak disegel, dan dapat diganti. Karena tidak tahu fungsi mana yang sebenarnya akan dipanggil terlebih dahulu, ia tidak dapat mengoptimalkan pemanggilan fungsi dan memanfaatkan lebih banyak informasi dalam membuat keputusan optimisasi, karena ia tidak benar-benar tahu fungsi mana yang akan dipanggil di waktu kode dikompilasi.
Pengoptimal adalah yang terbaik ketika mereka dapat mengintip ke dalam panggilan fungsi dan membuat optimasi yang benar-benar meratakan penelepon dan callee, atau setidaknya mengoptimalkan penelepon untuk bekerja paling efisien dengan callee. Mereka tidak dapat melakukan itu jika mereka tidak tahu fungsi mana yang sebenarnya akan dipanggil terlebih dahulu.
Apakah dia hanya berbicara di pantatnya?
Menggunakan biaya ini, yang sering berjumlah uang, untuk membenarkan mengubah ini menjadi standar pengkodean yang diterapkan secara umum pada umumnya sangat bodoh, terutama untuk tempat-tempat yang memiliki kebutuhan ekstensibilitas. Itulah hal utama yang ingin Anda perhatikan dengan pengoptimal prematur asli: mereka ingin mengubah masalah kinerja kecil menjadi standar pengkodean yang diterapkan secara seragam di seluruh basis kode tanpa memperhatikan keberlanjutan apa pun.
Saya sedikit tersinggung dengan kutipan "hacker C lama" yang digunakan dalam jawaban yang diterima, karena saya salah satunya. Tidak semua orang yang telah melakukan koding selama beberapa dekade mulai dari perangkat keras yang sangat terbatas telah berubah menjadi pengoptimal dini. Namun saya juga pernah bertemu dan bekerja dengan mereka. Tetapi tipe-tipe itu tidak pernah mengukur hal-hal seperti misprediksi cabang atau cache misses, mereka pikir mereka tahu lebih baik, dan mendasarkan gagasan mereka tentang inefisiensi dalam basis kode produksi kompleks berdasarkan pada takhayul yang tidak berlaku hari ini dan kadang-kadang tidak pernah berlaku. Orang-orang yang benar-benar bekerja di bidang yang kritis terhadap kinerja sering memahami bahwa pengoptimalan yang efektif adalah prioritas yang efektif, dan mencoba untuk menggeneralisasi standar pengkodean yang menurunkan kemampuan pemeliharaan untuk menghemat uang adalah prioritas yang sangat tidak efektif.
Uang adalah penting ketika Anda memiliki fungsi murah yang tidak melakukan banyak pekerjaan yang disebut satu miliar kali dalam lingkaran yang sangat ketat, kinerja-kritis. Dalam hal ini, kami akhirnya menghemat 10 juta dolar. Tidak ada gunanya mencukur uang receh ketika Anda memiliki fungsi yang disebut dua kali yang biayanya saja mencapai ribuan dolar. Tidak bijaksana menghabiskan waktu Anda menawar uang selama pembelian mobil. Layak menawar lebih dari satu sen jika Anda membeli satu juta kaleng soda dari produsen. Kunci optimalisasi yang efektif adalah memahami biaya-biaya ini dalam konteksnya yang tepat. Seseorang yang mencoba menghemat uang untuk setiap pembelian dan menyarankan agar semua orang mencoba menawar lebih banyak uang, apa pun yang mereka beli bukanlah pengoptimal yang terampil.