Apakah pengoptimalan mikro penting saat pengkodean?


178

Baru-baru ini saya mengajukan pertanyaan tentang Stack Overflow untuk mencari tahu mengapa isset () lebih cepat daripada strlen () di PHP . Ini menimbulkan pertanyaan seputar pentingnya kode yang dapat dibaca dan apakah peningkatan kinerja mikro-detik dalam kode itu patut dipertimbangkan.

Ayah saya adalah seorang pensiunan programmer, dan saya menunjukkan kepadanya jawabannya. Dia benar-benar yakin bahwa jika seorang koder tidak mempertimbangkan kinerja dalam kode mereka bahkan di tingkat mikro, mereka bukan programmer yang baik.

Saya tidak begitu yakin - mungkin peningkatan daya komputasi berarti kita tidak lagi harus mempertimbangkan peningkatan kinerja mikro semacam ini? Mungkin pertimbangan semacam ini tergantung pada orang yang menulis kode bahasa yang sebenarnya? (PHP dalam kasus di atas).

Faktor lingkungan bisa menjadi penting - Internet mengkonsumsi 10% dari energi dunia. Saya bertanya-tanya bagaimana borosnya beberapa mikro-detik kode ketika direplikasi triliunan kali pada jutaan situs web?

Saya ingin mengetahui jawaban yang lebih disukai berdasarkan fakta tentang pemrograman.

Apakah pengoptimalan mikro penting saat pengkodean?

Ringkasan 25 jawaban pribadi saya, terima kasih untuk semuanya.

Terkadang kita perlu benar-benar khawatir tentang optimisasi mikro, tetapi hanya dalam keadaan yang sangat jarang. Keandalan dan keterbacaan jauh lebih penting dalam sebagian besar kasus. Namun, mempertimbangkan optimasi mikro dari waktu ke waktu tidak ada salahnya. Pemahaman dasar dapat membantu kita untuk tidak membuat pilihan buruk yang jelas saat pengkodean seperti

if (expensiveFunction() || counter < X)

Seharusnya

if (counter < X || expensiveFunction())

( Contoh dari @ zidarsk8 ) Ini bisa menjadi fungsi yang tidak mahal dan karena itu mengubah kode akan menjadi optimasi mikro. Tetapi, dengan pemahaman dasar, Anda tidak perlu melakukannya, karena Anda akan menulisnya dengan benar sejak awal.


123
Nasehat ayahmu sudah ketinggalan zaman . Saya tidak akan bertanya berapa banyak itu meningkatkan kinerja. Saya akan bertanya di mana kemacetannya. Tidak masalah jika Anda meningkatkan kinerja bagian kode jika tidak ada perbedaan secara keseluruhan, tautan paling lambat Anda akan menentukan kecepatannya. Dalam PHP ini menulis ke jaringan (kecuali Anda dapat membuktikan ukuran IE sebaliknya); yang diterjemahkan ke dalam penulisan kode yang lebih mudah dibaca lebih penting.
Martin York

61
Jika kata kuncinya dipertimbangkan, dia tidak salah. Anda harus memiliki petunjuk tentang hal itu.
JeffO

37
Saya sedih karena kutipan Pengoptimalan Dini yang terkenal belum disebutkan: "Programmer menghabiskan banyak waktu memikirkan, atau mengkhawatirkan, kecepatan bagian nonkritis dari program mereka, dan upaya efisiensi ini sebenarnya memiliki negatif yang kuat dampak ketika debugging dan pemeliharaan dipertimbangkan. Kita harus melupakan efisiensi kecil, katakanlah sekitar 97% dari waktu: optimasi prematur adalah akar dari semua kejahatan . Namun kita tidak boleh melewatkan peluang kita dalam 3% kritis itu. "
Tamara Wijsman

13
Bisakah Anda memberikan sumber pada "10% dari energi dunia"?
Michael Easter

17
coder does not consider performance in their code even at the micro level, they are not good programmerssangat berbeda dari pengoptimalan mikro. Itu hanya coding yang bagus.
woliveirajr

Jawaban:


90

Saya berdua setuju dan tidak setuju dengan ayahmu. Kinerja harus dipikirkan lebih awal, tetapi optimasi mikro hanya harus dipikirkan lebih awal jika Anda benar - benar tahu bahwa persentase waktu yang tinggi akan dihabiskan di bagian kode yang terikat CPU kecil.

Masalah dengan optimasi mikro adalah bahwa hal itu biasanya dilakukan tanpa memiliki konsep bagaimana sebenarnya program menghabiskan lebih banyak waktu daripada yang diperlukan.

Pengetahuan ini berasal dari pengalaman melakukan penyetelan kinerja, seperti dalam contoh ini , di mana program yang tampaknya langsung, tanpa inefisiensi jelas, diambil melalui serangkaian diagnosis dan langkah-langkah percepatan, hingga 43 kali lebih cepat daripada di awal.

Apa yang diperlihatkannya adalah bahwa Anda tidak dapat benar-benar menebak atau intuisi di mana masalah akan terjadi. Jika Anda melakukan diagnosis, yang dalam kasus saya adalah jeda acak , baris kode yang bertanggung jawab untuk sebagian besar waktu terpapar secara istimewa. Jika Anda melihatnya, Anda mungkin menemukan kode pengganti, dan dengan demikian mengurangi waktu keseluruhan dengan kira-kira fraksi itu.

Hal-hal lain yang tidak Anda perbaiki masih memakan waktu sebanyak yang mereka lakukan sebelumnya, tetapi karena waktu keseluruhan telah berkurang, hal-hal itu sekarang mengambil fraksi yang lebih besar, jadi jika Anda melakukan semuanya lagi, fraksi itu juga dapat dihilangkan. Jika Anda terus melakukan ini pada beberapa iterasi, itulah cara Anda bisa mendapatkan speedup besar , tanpa harus melakukan optimasi mikro apa pun .

Setelah pengalaman semacam itu, ketika Anda mendekati masalah pemrograman baru, Anda mulai mengenali pendekatan desain yang pada awalnya menyebabkan inefisiensi. Dalam pengalaman saya, itu berasal dari desain berlebihan struktur data, struktur data non-normal, ketergantungan besar pada notifikasi, hal semacam itu.


120

Mikro-optimasi hanya penting jika angka mengatakan itu.

Persyaratan yang Anda kembangkan harus memiliki spesifikasi data kinerja, jika kinerja sama sekali merupakan masalah bagi klien atau pengguna. Ketika Anda mengembangkan perangkat lunak, Anda harus menguji kinerja sistem Anda terhadap persyaratan ini. Jika Anda tidak memenuhi persyaratan kinerja, maka Anda perlu membuat profil basis kode Anda dan mengoptimalkan sesuai kebutuhan untuk mencapai persyaratan kinerja. Setelah Anda berada dalam kinerja minimum yang disyaratkan, tidak perlu memeras kinerja lagi dari sistem, terutama jika Anda akan mengkompromikan pembacaan dan pemeliharaan kode lagi (dalam pengalaman saya, kode yang sangat dioptimalkan kurang dapat dibaca dan dapat dipelihara, tetapi tidak selalu). Jika Anda bisa mendapatkan keuntungan kinerja tambahan tanpa menurunkan atribut kualitas sistem lainnya,

Namun, ada beberapa contoh di mana kinerja sangat penting. Saya terutama berpikir dalam sistem waktu nyata dan sistem tertanam. Dalam sistem real-time, mengubah urutan operasi dapat memiliki efek besar pada pemenuhan tenggat waktu keras yang diperlukan untuk operasi yang tepat, bahkan mungkin memengaruhi hasil perhitungan. Dalam embedded system, Anda biasanya memiliki memori, daya CPU, dan daya yang terbatas (seperti pada daya baterai), jadi Anda perlu mengurangi ukuran biner Anda dan mengurangi jumlah komputasi untuk memaksimalkan umur sistem.


Di sisi lain, jika ada masalah antara menggunakan fungsi yang lebih lambat vs yang lebih cepat, tidak ada alasan untuk menggunakan fungsi yang lebih lambat - seperti di sini dalam kasus isset.
Mavrik

7
@ Malrik Itu benar. Jika Anda memiliki dua fungsi, X dan Y, dan Y lebih cepat dari X (setidaknya untuk kondisi khusus Anda), tidak ada alasan untuk tidak menggunakan Y, jika kode masih dapat dibaca dan dipelihara. Tetapi jika Anda tidak tahu tentang Y dan Anda perlu refactor kode untuk menggunakan Y, bukan X, dan kinerja (segmen kode itu) tidak menjadi masalah, maka tidak ada alasan untuk melakukan perubahan itu. Ini semua tentang pengorbanan - kinerja, waktu, biaya, usaha, keterbacaan / pemeliharaan, dan sebagainya.
Thomas Owens

2
Saya setuju dengan sepenuh hati, saya hanya ingin membuat poin ini ketika datang ke optimasi mikro - jika tidak ada biaya apa pun dalam hal keterbacaan / waktu, lakukanlah. Kalau tidak, jangan.
Mavrik

+1 kode yang sangat dioptimalkan kurang dapat dibaca dan dipelihara ... tetapi tidak selalu.
Boz

Lebih banyak kasus di mana kinerja penting: (1) bermain game; (2) sejumlah besar data; (3) situs web traffic tinggi; (4) respons terhadap UI yang sangat kompleks; (5) layanan yang seharusnya berjalan di latar belakang seperti pemeriksaan virus; (6) keuangan; (7) smartphone; dan seterusnya. Ini hampir tidak terbatas pada kasus-kasus esoterik seperti RTS dan sistem embedded.
Rex Kerr

103

Setiap kali ada yang bertanya tentang pengoptimalan , saya teringat akan kutipan dari Michael A. Jackson

Aturan Pertama Optimalisasi Program: Jangan lakukan itu.

Aturan Kedua tentang Pengoptimalan Program (hanya untuk para ahli!): Jangan lakukan itu dulu .

Kutipan dari Wikipedia dikoreksi untuk Inggris Inggris. * 8 ')

Tersirat dalam aturan kedua adalah membuat profil kode Anda dan hanya menghabiskan waktu mengoptimalkan hal-hal yang akan membuat perbedaan.

Saat memprogram dalam pertemuan, pernyataan ayahmu benar. Tapi itu jauh lebih dekat dengan logam daripada kebanyakan orang memprogram hari ini. Hari ini bahkan mencoba mengoptimalkan diri Anda (tanpa profil) dapat membuat kode Anda berjalan lebih lambat daripada jika Anda melakukan sesuatu dengan cara yang lebih umum, karena cara umum lebih mungkin dioptimalkan oleh kompiler JIT modern .

Bahkan di C Anda harus cukup pandai optimasi untuk tahu lebih banyak tentang cara mengoptimalkan bagian kode daripada kompiler.

Jika Anda tidak terbiasa dengan apa yang dibicarakan Ulrich Drepper dalam makalahnya yang luar biasa Apa Yang Harus Setiap Programmer Ketahui tentang Memori , maka Anda mungkin berada di pihak yang kalah bahkan mencoba mengoptimalkan diri Anda. Bertolak belakang dengan judul makalah (yang sebenarnya merupakan penghormatan kepada David Goldberg yang sama fantastisnya. Apa yang Harus Diketahui Setiap Ilmuwan Tentang Aritmatika Titik Apung ) tidak memiliki tingkat pemahaman ini tidak lantas menghentikan Anda menjadi seorang programmer yang baik, hanya jenis yang berbeda. programmer.

isset()vs. strlen()dalam PHP

Saya tidak tahu PHP, jadi sebenarnya tidak jelas apa isset()yang harus dilakukan. Saya dapat menyimpulkannya dari konteks, tetapi ini berarti bahwa itu akan sama tidak jelas untuk programmer PHP pemula dan bahkan mungkin menyebabkan programmer lebih berpengalaman untuk mengambil dua kali. Ini adalah jenis penggunaan bahasa secara idiomatis yang dapat membuat pemeliharaan menjadi mimpi buruk.

Bukan hanya itu, tetapi tidak ada jaminan yang isset()akan selalu lebih efisien, hanya karena sekarang lebih efisien. Pengoptimalan sekarang mungkin bukan pengoptimalan tahun depan, atau dalam 10 tahun. CPU, sistem, kompiler meningkat dan berubah seiring waktu. Jika kinerja PHP strlen()bermasalah, PHP mungkin akan dimodifikasi di masa mendatang, maka semua optimasi isset () mungkin perlu dihapus untuk mengoptimalkan kode sekali lagi.

Setiap optimasi memiliki potensi untuk menjadi anti-optimisasi di masa depan , jadi harus dianggap sebagai kemungkinan bau kode, agar seminimal mungkin.

Contoh dari pengalaman pribadi

Sebagai contoh dari anti-optimasi , saya pernah harus membersihkan basis kode besar yang diisi dengan kode formulir if x==0 z=0 else z=x*ykarena seseorang telah membuat asumsi bahwa perkalian floating point selalu akan lebih mahal daripada cabang. Pada arsitektur target asli optimasi ini membuat kode menjalankan urutan besarnya lebih cepat, tetapi waktu berubah.

Ketika kami mencoba menggunakan kode ini pada CPU yang lebih modern yang sangat pipelined kinerjanya sangat buruk - setiap pernyataan ini menyebabkan flush pipeline. Menyederhanakan semua baris kode ini hanya untuk z=x*ymembuat program menjalankan urutan besarnya lebih cepat pada arsitektur baru, mengembalikan kinerja yang hilang oleh anti-optimasi .

Masalah yang biasanya harus kami optimalkan untuk hari ini sangat berbeda dengan yang harus kami optimalkan selama 20 atau bahkan 10 tahun yang lalu.

Kemudian kami khawatir melakukan pekerjaan paling banyak per siklus clock, sekarang kami lebih cenderung khawatir tentang flush pipeline, mispredictions cabang dan miss cache pada level CPU, tetapi kunci dan komunikasi antarproses menjadi jauh lebih signifikan ketika kami pindah ke multi- arsitektur proses dan multi-prosesor. Makalah Drepper benar-benar dapat membantu memahami banyak masalah ini.


3
Pipeline flush dan cache miss adalah apa yang ingin Anda hindari: D Mereka memiliki biaya yang mengerikan. tetapi hanya pada bagian-bagian kode yang mengeluarkan mereka banyak banyak banyak berkali-kali.
deadalnix

7
Satu hal yang akan saya tambahkan adalah bahwa kompiler telah datang jauh dan akan mengoptimalkan banyak hal untuk Anda. AFAIK, mereka lebih baik mengoptimalkan kode yang bersih dan mudah dibaca daripada hal-hal rumit.
Becuzz

3
+1 untuk memberikan contoh nyata optimasi mikro yang menghabiskan waktu - dan mengungkapkan bahwa Michael Jackson adalah seorang programmer.
Boz

1
+1 Sebagai contoh. Ini menggambarkan dengan sempurna mengapa Anda harus meninggalkan transformasi sepele ke kompiler.
back2dos

1
@Rex Kerr> dalam contoh, biaya berasal dari percabangan, yang menyebabkan flush pipeline CPU. Penggandaan titik apung juga mahal. Apa yang lebih mahal tergantung sangat pada FPU dan panjang pipa CPU yang menjalankan kode. Saya tidak akan terkejut bahwa kode ini berjalan lebih cepat pada CPU lama yang memiliki pipa lebih pendek dan FPU kurang efisien daripada CPU saat ini.
deadalnix

84
  1. Tulis kode, yang bersih, ringkas, sederhana dan jelas.
  2. Buat tes kinerja untuk mengidentifikasi kemacetan.
  3. Optimalkan bagian-bagian penting.

Sebagai aturan praktis: 95% dari kode Anda dijalankan 5% dari waktu. Tidak ada gunanya mengoptimalkan sebelum profil / benchmark kode Anda dan melihat mana 5% yang dijalankan 95% dari waktu.

Setiap orang idiot dapat melakukan optimasi mikro dan setiap kompiler / runtime yang layak akan melakukan ini untuk Anda.
Mengoptimalkan kode yang baik itu sepele. Menulis kode yang dioptimalkan dan berusaha membuatnya menjadi baik setelah itu sangat membosankan dan tidak berkelanjutan.

Jika Anda benar-benar memperhatikan kinerja, maka jangan gunakan PHP untuk kode penting kinerja. Temukan kemacetan dan tulis ulang dengan ekstensi C. Bahkan mikro-mengoptimalkan kode PHP Anda di luar titik kebingungan tidak akan membuat Anda mendapatkan kecepatan yang hampir sama.

Secara pribadi, saya suka melakukan optimasi mikro banyak ketika saya mulai pemrograman. Karena sudah jelas. Karena itu memberi Anda imbalan dengan cepat. Karena Anda tidak harus mengambil keputusan penting. Ini adalah cara menunda yang sempurna . Ini memungkinkan Anda untuk melarikan diri dari bagian yang sangat penting dalam pengembangan perangkat lunak: Desain sistem yang dapat diskalakan, fleksibel, dapat diperluas, dan kuat.


2
Jawaban terbaik bagi saya ditemukan, secara luar biasa, dalam Panduan Pengembang Bugzilla: "Jika Anda mencoba untuk menjadi pintar daripada mencoba untuk dibaca, maka mungkin Anda mencoba untuk membuat segalanya" lebih cepat? "Jika demikian, ingat saja : jangan selesaikan masalah sebelum Anda mengetahuinya. Jika Anda tidak tahu (dengan tes terperinci dan aktual) bahwa kode Anda lambat, jangan khawatir membuatnya "lebih cepat." Ini tidak hanya terbatas pada optimisasi - banyak programmer yang terus-menerus menyelesaikan masalah yang belum pernah dialami oleh siapa pun. bugzilla.org/docs/developer.html#general
Marco

7
Saya biasanya setuju - kecuali untuk satu baris, saya berpendapat bahwa "setiap idiot berpikir mereka dapat mengoptimalkan mikro" ...;)
Nim

@ Nim: Poin diambil;)
back2dos

26

Saya akan setuju dengan ayah Anda: "Jika seorang pembuat kode tidak mempertimbangkan kinerja dalam kode mereka bahkan di tingkat mikro, mereka bukan programmer yang baik." Kuncinya adalah "mempertimbangkan kinerja". Itu tidak setara dengan "melakukan optimasi mikro di setiap langkah".

Saya setuju dengan sebagian besar komentar lain - apa yang digunakan untuk membuat program C lebih cepat mungkin tidak melakukannya hari ini - tetapi ada hal-hal serius lainnya untuk dipertimbangkan: Haruskah saya menggunakan C atau C ++? Kelas dengan operator kelebihan beban sederhana dapat mematikan kinerja jika Anda sering menggunakannya. Apakah itu penting? Itu tergantung pada aplikasi Anda, tetapi jika Anda bahkan tidak MEMPERTIMBANGKAN, Anda bukan programmer yang sangat baik. Beberapa orang mungkin menganggapnya sekitar 2 milidetik dan mengabaikannya, tapi saya pikir terlalu banyak yang bahkan tidak menganggapnya.

Kenyataannya adalah bahwa dengan optimasi, kode dapat menjadi lebih sulit untuk dibaca. Kode akan membutuhkan waktu lebih lama untuk ditulis. Kode akan berada di suatu tempat antara sedikit lebih cepat dan urutan besarnya lebih cepat (itu jarang terjadi). Pelanggan Anda mungkin tidak akan tahu bedanya.

Kenyataan lain adalah bahwa orang suka menggunakan kembali kode, dan di mana kode itu mungkin sangat berbeda dari ketika Anda menulisnya. Tiba-tiba orang mungkin peduli.

Sebagai contoh, katakan Anda menulis sesuatu seperti Angry Birds di PC, atau untuk konsol game. Anda mengabaikan pengoptimalan dalam sistem fisika dan sistem grafis Anda - karena 2,5 GHz dual core pada dasarnya adalah minimum hari ini, dan gim Anda berfungsi cukup baik. Kemudian ponsel pintar datang dan Anda ingin porting. Oh sial, inti ARM 600 MHz ?

Pikirkan situs web - sesuatu yang dilemparkan bersama di akhir pekan seperti Hot or Not . Anda menggunakan basis data apa pun yang berguna, tulis semuanya dengan perkembangan cepat, luncurkan dengan mengirim email ke teman-teman Anda URL. Tiga bulan kemudian server Anda sekarat karena kelebihan beban dan tidak ada yang dapat Anda lakukan untuk meningkatkannya. Itu terjadi setiap saat. Situs web terbesar memiliki tagihan listrik yang diukur dalam ratusan kilowatt atau bahkan megawatt. Pikirkan tentang itu, ada megawatt yang harus disimpan melalui optimasi kode.

Seperti kata ayahmu, kamu setidaknya harus mempertimbangkannya . Kebanyakan orang bahkan tidak tahu berapa banyak kinerja di atas meja dan mengabaikannya dengan sindiran cepat tentang "optimasi prematur" dan "jangan lakukan itu". Ini bukan programmer yang baik.

Ini bukan pendapat populer di situs-situs ini. Sampai jumpa poin reputasi ....


3
Tentu, Anda harus mempertimbangkannya (di belakang kepala Anda) dan biasanya menolaknya, kecuali jika itu terbukti sepadan. Anda perlu mempertimbangkan bahwa optimasi biasanya menurunkan keterbacaan kode dan dapat meningkatkan waktu yang dibutuhkan untuk kode dan memelihara dengan faktor 10 atau lebih. Jika program ini tidak intensif CPU, seringkali tidak diperlukan. Ketahuilah bahwa kompiler Anda biasanya lebih baik dalam mengoptimalkan daripada Anda, dan bahwa banyak optimasi Anda benar-benar akan merusak kinerja. Jika tidak layak waktu Anda untuk menguji optimasi dan profil Anda, itu tidak layak waktu Anda untuk mengoptimalkan.
dr jimbob

3
Contoh Angry Birds Anda menunjukkan dengan tepat mengapa Anda tidak harus mengoptimalkan secara prematur. Dalam porting dari desktop ke konsol ke perangkat seluler, Anda berurusan dengan (setidaknya) tiga jenis perangkat keras yang sangat berbeda dan pengoptimalan untuk satu orang mungkin lebih menyakitkan daripada membantu yang lain. Lebih buruk lagi, optimalisasi akan membuat kode lebih sulit untuk dipahami, oleh karena itu lebih sulit untuk port. Tentu, pilih algoritma yang efisien dari awal, tetapi simpan optimasi mikro untuk fase penyesuaian kinerja saat data nyata akan memberi tahu Anda di mana masalahnya ada di setiap platform.
Caleb

@ Caleb: Contoh Angry Birds menggambarkan mengapa tidak mengoptimalkan perangkat keras tertentu. Ini juga menggambarkan bagaimana Anda dapat membangun seluruh aplikasi tanpa repot-repot melakukan optimasi "tingkat C" yang lebih umum dan kemudian terbakar. Sebenarnya tidak terbakar, tetapi mengalami kesulitan melampaui niat awal Anda.
phkahler

25

Pertama-tama mari kita ambil kasus Anda: PHP

  • Saya tidak berpikir PHP adalah sejenis bahasa (baik karena sifatnya dan domain aplikasi utamanya) yang perlu Anda khawatirkan tentang "optimasi mikro" ini. Kode PHP sebagian besar dioptimalkan dengan caching opcode.
  • Program yang ditulis dalam PHP tidak terikat dengan CPU, tetapi sebagian besar terikat dengan I / O , jadi optimasi ini tidak akan sepadan dengan waktu Anda.
  • Apa pun yang HARUS Anda optimalkan mungkin harus dimasukkan ke ekstensi C dan kemudian dimuat secara dinamis di runtime PHP
  • Jadi seperti yang Anda lihat, kami tidak mendapatkan insentif dengan mengoptimalkan kode kami dalam PHP - di sisi lain, jika Anda menghabiskan waktu itu dalam membuat kode PHP lebih mudah dibaca dan dipelihara - yang akan memberi Anda lebih banyak dividen.

Secara umum,

Saya tidak akan menghabiskan "TOOOOO" banyak waktu untuk mengoptimalkan kode saya dalam bahasa yang dinamis seperti Python atau Ruby - karena, mereka TIDAK dirancang untuk tugas-tugas pengolah angka intensif CPU. Mereka memecahkan berbagai kelas masalah di mana pemodelan situasi dunia nyata dengan cara yang rumit (yang mudah dibaca dan dipelihara) - yang disebut ekspresivitas - lebih penting daripada kecepatan. Jika kecepatan adalah perhatian utama, mereka tidak akan dinamis sejak awal.

Untuk program yang dikompilasi (C ++, Java), optimasi lebih penting. Tetapi di sana juga, pertama-tama Anda harus melihat sifat / domain / tujuan dari program yang Anda tulis. Anda juga harus hati-hati mempertimbangkan waktu untuk mengoptimalkan mikro dengan keuntungan dari optimasi itu. Jika Anda membutuhkan lebih banyak optimasi, maka Anda sebaiknya mempertimbangkan untuk mengambil langkah ke bawah - dan kode bagian-bagian kode Anda di assembler.

Jadi, untuk menjawab pertanyaan awal Anda - "Apakah optimisasi mikro penting saat pengkodean?" -- Jawabannya adalah, tergantung --

  • Apa yang Anda lakukan: domain aplikasi, kompleksitas?
  • Apakah peningkatan kecepatan mikrodetik SANGAT penting untuk program Anda?
  • Optimalisasi seperti apa yang paling menguntungkan? Mungkin tidak selalu optimasi kode, tetapi sesuatu yang eksternal.
  • Berapa banyak "kebaikan" (dalam hal kecepatan) yang Anda peroleh dari waktu Anda berinvestasi dengan mengoptimalkan mikro?
  • Dapatkah kecepatan yang lebih baik dicapai dengan cara lain - dengan mengubah perangkat keras, RAM & prosesor, mengeksekusi kode paralel, atau pada sistem terdistribusi?

Tidak hanya mikro-optimasi (optimasi kode dalam hal ini) memakan waktu, itu "mendistorsi" keterbacaan alami kode Anda, sehingga membuatnya pemeliharaan berat. Selalu menganggapnya sebagai upaya terakhir - selalu mencoba untuk mengoptimalkan seluruh aplikasi dengan mengadopsi perangkat keras yang lebih baik dan arsitektur yang lebih baik daripada mengoptimalkan file kode individual.


18

Tampaknya ada banyak jawaban yang mengatakan optimisasi mikro

semua tentang pengorbanan - kinerja, waktu, biaya, usaha, keterbacaan / pemeliharaan, dan sebagainya.

Tapi saya tahu ada beberapa optimasi di mana tidak ada dampak keterbacaan, dan saya hanya ingin melakukan itu untuk bersenang-senang. Saya melihat pada beberapa tugas sekolah saya (yang semuanya berbasis kecepatan), bahwa selalu baik untuk mempertimbangkan optimasi mikro ketika menulis pernyataan bersyarat seperti:

if (counter < X && shouldDoThis()) // shouldDoThis() is an expensive function

selalu lebih baik daripada

if (shouldDoThis() && counter < X ) 

Ada beberapa cara untuk "mempercepat" kode Anda seperti itu dan perbedaannya biasanya diabaikan (tidak selalu demikian), tetapi saya merasa lebih baik jika saya menulis seperti itu.

Saya tidak tahu apakah ada orang yang menganggap ini sebagai optimasi yang sebenarnya, tetapi saya pikir seorang programmer harus tahu dan mempertimbangkan hal-hal ini ketika menulis kode mereka.


2
Mungkin tidak penting untuk kasus khusus ini. Namun saya pikir itu adalah sangat penting untuk dapat mengenali optimasi seperti ini sehingga ketika tidak peduli, Anda tidak harus menghabiskan tidak perlu waktu profiling dan mengoptimalkan setelah fakta.
tskuzzy

4
Ini adalah contoh yang sangat berbahaya . Sebuah optimasi harus tidak pernah mengubah perilaku . Bahkan menyarankan bahwa cheap() && expensive()ini adalah optimalisasi expensive () && cheap()mengundang orang untuk secara buta mensubstitusi satu dengan yang lain tanpa memperhatikan perubahan semantik signifikan yang dibuatnya (dalam bahasa di mana &&operator hubung singkat).
Mark Booth

5
Jika fungsi tidak memiliki efek samping, mereka setara dan lebih cepat. Jika mereka memiliki efek samping, pertama-tama jangan menulis kode seperti ini. Saya bahkan akan mengatakan ini adalah yang harus dilakukan karena kebiasaan - kecuali jika itu benar-benar mengubah perilaku.
phkahler

3
@ MarkBooth Saya harus setuju dengan phkahler di sini, tidak ada fungsi ini yang memiliki efek samping! Urutan condionos dalam pernyataan if tidak boleh mempengaruhi hasil program. Contoh saya akan lebih baik ditulis sebagai if (x<100 && isPrime(x)), hanya untuk membuatnya lebih jelas.
zidarsk8

1
@ zidarsk8 - Jika pengoptimalan mengubah apa pun selain kecepatan eksekusi, maka itu bukan pengoptimalan . Sebagai programmer, kita sering harus pragmatis , dan terkadang itu berarti kita tidak dapat menjamin bahwa semua fungsi yang digunakan dengan operator hubung singkat adalah murni - terutama ketika kode kita memanggil perpustakaan pihak ketiga yang tidak dapat kita kendalikan. Dalam situasi itu Anda harus berhati-hati bahwa programmer yang tidak berpengalaman tidak dianjurkan untuk memperkenalkan bug atas nama optimasi .
Mark Booth

11

Di awal karir saya, pernyataan yang tidak jelas seperti, "jangan mengoptimalkan mikro" menyebabkan banyak kebingungan. Semuanya bersifat tidak langsung; jadi, alasan orang mengatakan, "praktik terbaik" daripada "lakukan ini".

"Praktik terbaik" adalah pilihan utama mengingat semua keadaan. Sebagai contoh, LINQ dan Entity Framework harus digunakan sebagai pengganti inline SQL. Di perusahaan saya, kami menggunakan SQL Server 2000 . SQL Server 2000 tidak mendukung Entity Framework. Praktik terbaik membutuhkan:

  • Menjual bos saya dengan ide membeli versi baru SQL Server yang berarti beberapa ribu dolar.
  • Menjual pengembang dengan ide mempelajari teknologi baru.

Saya tahu dari pengalaman, ini tidak akan terjadi. Jadi, saya bisa berhenti, stres tanpa akhir atau tidak mengikuti praktik terbaik.

Ada pertimbangan politis, teknis, dan moneter di balik keputusan yang memengaruhi hasil keseluruhan. Ingat fakta ini ketika membuat keputusan dan pilih pertempuran Anda dengan bijak.

" Untuk segala sesuatu ada musim, ada waktu untuk setiap kegiatan di bawah langit. "


1
BTW, Anda bisa menggunakan Dapper sebagai alternatif mikro-ORM untuk inline SQL.
Dan

2
LINQ and Entity Framework should be used in lieu of inline SQL- Sampai Anda benar-benar perlu inline SQL untuk mengoptimalkan sesuatu; SQL yang dihasilkan EF tidak selalu optimal.
Robert Harvey

1
fwiw, jika bos Anda khawatir tentang biaya lisensi SQL 2k8 (atau apa pun yang mungkin saat ini), Anda harus menunjukkan bahwa sudah cukup umur untuk muncul di EOL SANGAT segera (jika belum)
warren

@warren - Beberapa perusahaan tidak mempertimbangkan hal tersebut. Bagi sebagian orang, jika masih "berfungsi" maka mereka tidak akan memutakhirkan. Dengan kerja, maksud saya server masih berjalan. Kami sudah melihat kurangnya dukungan dengan EF. Itu tidak cukup untuk meyakinkan mereka untuk membelanjakan uang.
P.Brian.Mackey

1
Asal tahu saja, Anda dapat menggunakan EF dengan SQL 2000. Desainer tidak bekerja, tetapi kerangka kerja sebenarnya tidak mendukung SQL 2000. Untuk menyiasati batasan desainer, Anda dapat membuat database lokal di sql 2008 express dengan skema yang sama sebagai database sql 2000, arahkan perancang itu untuk menghasilkan semua kelas, kemudian masuk ke file .edmx dan ubah versi database target menjadi 2000 dan arahkan string koneksi ke database sql server 2000 Anda. Bukan solusi terbaik, tetapi jika Anda tidak dapat memutakhirkannya, itu berfungsi.
Neil

8

Ini selalu merupakan tradeoff.

Pertama, industri komputer adalah tentang uang pada akhirnya. Apa yang perlu Anda lakukan sebagai pengembang adalah menghasilkan nilai bagi pelanggan sehingga Anda mendapatkan uang (itu penyederhanaan yang berlebihan tetapi poin utamanya ada di sini).

Waktu pengembang membutuhkan biaya. Tenaga mesin juga membutuhkan uang. Biasanya, biaya kedua ini jauh lebih rendah daripada yang pertama. Jadi, ini adalah modal untuk memiliki kode yang dapat dibaca dan kode yang dapat dipelihara, sehingga pengembang dapat menghabiskan sebagian besar waktunya untuk memberikan nilai.

Optimalisasi mikro dapat, dalam beberapa kasus, menjadi penting. Tetapi mereka biasanya melibatkan kode yang kurang dapat dibaca, atau kode yang tidak dapat diperpanjang (ini bukan contoh contoh dari tautan Anda, tetapi secara umum, itu) Ini akan dikenakan biaya pada waktu pengembang titik tertentu. Kali ini lebih mahal daripada daya mesin, ini sia-sia.

Kedua, optimasi mikro dalam proyek besar dapat membuatnya semakin sulit untuk dipertahankan / dikembangkan. Masalah dengan itu adalah bahwa ketika berevolusi, beberapa optimasi lain sekarang tidak mungkin dilakukan. Dengan aplikasi yang berkembang, Anda biasanya akan berakhir dengan solusi yang lebih lambat daripada yang Anda miliki tanpa melakukan optimasi tersebut.

Ketiga, optimasi sering tidak jelas karena kompleksitas algoritma umumnya akan mengatasi optimasi mikro apa pun yang bisa Anda lakukan jika set data tumbuh. Sayangnya, karena optimasi mikro membuat kode Anda lebih sulit untuk dipertahankan / dikembangkan, optimasi mereka mungkin lebih sulit untuk dilakukan.

Kadang, nilainya ada dalam pengoptimalan ini (pikirkan tentang program kritis latensi, seperti dalam video game atau autopilot pesawat terbang). Tetapi ini harus ditunjukkan. Biasanya program Anda menghabiskan sebagian besar waktu dalam bagian kode yang terbatas. Apa pun optimasi mikro yang Anda lakukan, Anda tidak akan pernah mendapatkan program Anda lebih cepat secara bernilai tanpa mengidentifikasi hambatan dan mengerjakan bagian ini.

Mengajukan pertanyaan seperti yang Anda lakukan menunjukkan bahwa Anda tidak membandingkan masalah pada program yang sebenarnya. Dalam hal ini, Anda bisa melakukan trik dan perhatikan apakah itu lebih cepat atau tidak. Jadi Anda bertanya sebelum mengalami masalah. Di sinilah masalahnya. Anda menangani masalah optimasi dengan cara yang salah.

Karena pemeliharaan dan evolusi biasanya lebih berharga daripada optimasi mikro, pastikan untuk memiliki antarmuka yang tepat sebelum melakukan apa pun. Kemudian jika bagian dari program Anda cukup abstrak untuk satu sama lain, Anda dapat mengoptimalkan mikro satu tanpa mengacaukan semuanya. Ini mengharuskan antarmuka Anda berjalan cukup lama untuk dapat dipercaya.


"Selalu ada tradeoff". Benar, mengurangi satu variabel akan meningkatkan yang lain, jika program berada pada kurva tradeoff . Dalam pengalaman saya, sebagian besar program tidak berada di dekat kurva tradeoff, dan memiliki banyak ruang untuk kedua variabel untuk dikurangi.
Mike Dunlavey

+1 pemeliharaan dan evolusi lebih berharga daripada optimasi mikro. Meskipun saya yakin bahwa industri komputer lebih dari sekadar uang? Misalnya, open source, pendidikan, inovasi, tata kelola, komunitas, dll. Saya yakin uang dapat ditemukan pada dasarnya, tetapi itu berlaku untuk sebagian besar hal.
Boz

@Boz kay> Ini sebagian benar. Pertama karena bos dan pelanggan Anda kebanyakan tidak tahu apa-apa tentang thoses dan peduli tentang uang. Jika Anda ingin mempromosikan beberapa alat sumber terbuka, Anda harus memberi tahu mereka bagaimana hal itu akan meningkatkan merek perusahaan atau bagaimana hal itu akan mengurangi biaya pengembangan. Plus, membuat pengembang senang adalah cara untuk mendapatkan pengembang yang baik di perusahaan Anda. Dev yang baik menghasilkan uang (kebanyakan membuang kualitas dan inovasi). Pada akhirnya, uang adalah kuncinya. Dan saya menulis bahwa dari komputer linux saya menjadi pendukung perangkat lunak gratis yang hebat. Hal yang sama berlaku untuk pendidikan.
deadalnix

8

Kinerja adalah Fitur

Artikel Jeff Atwood adalah artikel hebat untuk membangun situs web berkinerja tinggi dan pentingnya melakukannya ...

Yang mengatakan, jangan fokus pada optimasi mikro sampai Anda perlu. Ada lebih banyak optimasi bermanfaat biaya yang dapat Anda lakukan. Fokus pada arsitektur, bukan kode. Sebagian besar situs web yang saya lihat yang berkinerja lambat memiliki masalah tingkat tinggi (lapisan layanan web yang tidak perlu, desain basis data yang buruk, arsitektur yang terlalu rumit) yang tidak hanya memengaruhi kinerja tetapi juga mendarah daging dan sulit untuk diperbaiki.

Saat Anda membangun situs web, kode sisi klien dan logika database jauh lebih mungkin menyebabkan masalah kinerja daripada kode sisi server Anda. Seperti apa pun, jika Anda memiliki masalah kinerja Anda akan tahu, bahkan lebih baik profil kode Anda dan Anda dapat menemukannya sejak awal.


7

Waktu pengembang lebih mahal daripada waktu komputer. Biasanya itu yang ingin Anda optimalkan. Tapi:

  • Ada perbedaan antara optimasi mikro dan kompleksitas algoritmik. Luangkan cukup waktu untuk yakin bahwa Anda menggunakan algoritma yang tepat .
  • Pastikan Anda mengajukan pertanyaan yang tepat, select (select count(*) from foo) >= 1bukan hal yang sama select exists(select 1 from foo).
  • beberapa idiom bahasa populer hanya karena lebih cepat, tidak masalah untuk menggunakannya, karena sebagian besar pengguna bahasa yang fasih akan terbiasa dengannya. (contoh Anda adalah contoh yang baik).

7

Apa yang ingin Anda optimalkan?

  • Kinerja perangkat lunak?
  • Keandalan?
  • Produktivitas pemrogram?
  • Kepuasan pelanggan?
  • Efisiensi tenaga?
  • Kemampuan perawatan?
  • Waktunya memasarkan?
  • Biaya?

"Optimalkan" tidak selalu berarti membuat kode berjalan secepat mungkin. Ada kalanya menemukan cara tercepat mutlak untuk melakukan sesuatu itu penting, tapi itu tidak terlalu umum di kebanyakan kode. Jika pengguna tidak dapat melihat perbedaan antara 50 dan 100 mikrodetik, secara efektif tidak ada perbedaan antara keduanya dalam kode yang hanya akan berjalan sesekali. Ini sebuah contoh:

Jika Anda perlu terus memperbarui tampilan panjang input pengguna dan jumlah waktu yang dibutuhkan salah satu dari dua rutinitas untuk menentukan bahwa panjangnya jauh lebih kecil daripada waktu antara dua penekanan tombol berurutan, benar-benar tidak masalah yang rutin Kau gunakan. Di sisi lain, jika Anda perlu menentukan panjang satu miliar string, Anda mungkin ingin memperhatikan perbedaan kinerja antara rutinitas yang berbeda. Dalam kasus pertama, Anda mungkin lebih suka menulis kode yang mudah dimengerti dan diverifikasi; dalam kasus kedua, Anda mungkin bersedia memperdagangkan keterbacaan untuk kecepatan.

Bagaimanapun, jika Anda akan mengoptimalkan kode Anda, Anda harus membuat profil kode Anda sebelum dan sesudah perubahan yang Anda lakukan. Program akhir-akhir ini cukup rumit sehingga seringkali sulit menentukan di mana kemacetannya; pembuatan profil membantu Anda mengoptimalkan kode yang tepat dan kemudian menunjukkan bahwa optimasi yang Anda lakukan benar-benar berhasil.

Anda tidak mengatakan kapan ayah Anda pensiun atau pemrograman apa yang dia lakukan, tetapi reaksinya tidak mengejutkan. Secara historis, memori, penyimpanan sekunder, dan waktu komputasi semuanya mahal, dan kadang-kadang sangat mahal. Hari-hari ini, semua hal itu menjadi sangat murah dibandingkan dengan waktu programmer. Pada saat yang sama, prosesor dan kompiler menjadi dapat mengoptimalkan kode dengan cara yang tidak pernah bisa diprogram oleh programmer. Hari-hari ketika programmer menggunakan trik kecil untuk membuat beberapa instruksi mesin di sana-sini sebagian besar hilang.


1
+1 Belum lagi bahwa dalam beberapa tahun terakhir, perangkat seluler sekali lagi menjadi sangat bergantung pada optimasi kode. Seseorang yang tidak menulis kode yang dioptimalkan atau setidaknya menganggapnya mungkin mengalami kesulitan mendapatkan aplikasi intensif CPU untuk berjalan dengan lancar di perangkat seluler.
Styler

+1 sangat mirip dengan daftar kemungkinan optimisasi Anda. Dia menggunakan perakitan / fortran
Boz

@Styler: tidak akan lama sampai perangkat mobile memiliki CPU quad core dengan memori GB, kami sudah memiliki smartphone dual core.
Lie Ryan

@Lie Ryan: ya ini benar, tetapi seperti kebanyakan perintis, mereka harus bepergian dengan perahu kayu;)
Styler

7

Tidaklah penting untuk mengoptimalkan mikro saat menulis kode. Optimalisasi harus dilakukan dengan bantuan profiler, mengoptimalkan kode di tempat yang penting.

NAMUN , seorang programmer harus mencoba untuk menghindari melakukan hal-hal yang jelas bodoh saat menulis kode.

Misalnya, jangan lakukan operasi mahal berulang dalam satu lingkaran. Simpan nilai dalam variabel di luar loop dan gunakan itu. Jangan lakukan hal-hal seperti perbandingan string atau regex berulang-ulang dalam fungsi yang sering disebut, ketika Anda bisa naik level, lakukan perbandingan dan membuatnya menjadi integer atau referensi fungsi atau kelas turunan.

Hal-hal ini mudah diingat oleh programmer yang berpengalaman dan hampir selalu meningkatkan kualitas kode.


Menyadari saya harus lebih jelas dalam mengedit pertanyaan saya, saya mengatakan hal yang sama - saya telah memperbaruinya.
Boz

7

Saat memutuskan apa yang harus dioptimalkan, selalu ingat hukum Amdahl . Lihat tautan untuk perhitungan matematika yang akurat; pernyataan bernas untuk diingat adalah:

Jika satu bagian dari program Anda menyumbang 10% dari runtime-nya, dan Anda mengoptimalkan bagian itu untuk menjalankan dua kali lebih cepat, program secara keseluruhan hanya akan mempercepat sebesar 5%.

Inilah sebabnya mengapa orang selalu mengatakan itu tidak layak mengoptimalkan bagian dari program Anda yang tidak menempati lebih dari beberapa persen dari total runtime. Tapi itu hanya kasus khusus dari prinsip yang lebih umum. Hukum Amdahl memberi tahu Anda bahwa jika Anda perlu membuat seluruh program berjalan dua kali lebih cepat, Anda harus mempercepat setiap bagian dengan rata-rata 50%. Ini memberitahu Anda bahwa jika Anda perlu memproses dua puluh gigabyte data, hanya ada dua cara untuk membuatnya lebih cepat daripada waktu yang dibutuhkan untuk membaca dua puluh gigabyte dari disk: dapatkan disk yang lebih cepat, atau buat data lebih kecil.

Jadi apa yang dikatakan hukum Amdahl tentang optimasi mikro? Dikatakan bahwa mereka mungkin layak jika mereka berlaku secara menyeluruh. Jika Anda dapat mencukur satu persen dari runtime setiap fungsi di program Anda, selamat! Anda telah mempercepat program dengan satu persen. Apakah itu layak dilakukan? Nah, sebagai seorang pembuat kompiler saya akan senang menemukan optimasi yang melakukan itu, tetapi jika Anda melakukannya dengan tangan, saya akan mengatakan mencari sesuatu yang lebih besar.


1
+1 untuk kutipan Amdahl, tapi saya tidak setuju dengan "untuk membuat seluruh program berjalan dua kali lebih cepat, Anda perlu mempercepat setiap bagian". Saya akan mengatakan Anda tidak benar-benar mempercepat "bagian". Sebaliknya, Anda menemukan pekerjaan yang tidak perlu, dan menghilangkannya. Terutama pemanggilan fungsi, jika programnya lebih besar dari mainan. Sebagian besar pemikiran umum tentang kinerja tampaknya mengabaikan sepenuhnya pentingnya menemukan seluruh cabang pohon panggilan yang tidak perlu (yang bisa berupa instruksi tunggal), dan memotongnya.
Mike Dunlavey

Iblis ada di kata "rata-rata" di sana. Secara matematis kasus bahwa untuk mempercepat program sebesar 50% setiap bagian harus dipercepat rata-rata 50% . Sekarang, jika Anda dapat membagi program menjadi pekerjaan yang membutuhkan 75% runtime dan yang lain membutuhkan 25%, dan mempercepat yang sebelumnya 3x, itu akan memberi Anda 50% secara keseluruhan meskipun tidak melakukan apa pun pada pekerjaan yang terakhir. Tetapi kasus yang jauh lebih umum adalah bahwa ada puluhan "pekerjaan" yang masing-masing memakan waktu kurang dari 5% dari runtime - dan kemudian Anda harus mempercepat atau menyingkirkan banyak dari mereka.
zwol

Saya pikir ada kasus yang lebih umum. Ada "pekerjaan" yang menghabiskan 50% dari waktu, tetapi Anda tidak benar-benar membutuhkannya , jadi Anda menghapusnya sepenuhnya, mengurangi waktu keseluruhan dengan jumlah itu, lalu ulangi. Saya tahu ini sulit diterima - bahwa program dapat menghabiskan sebagian besar waktu untuk melakukan hal-hal yang (di belakang) sama sekali tidak perlu. Tapi ini contoh kanonik saya .
Mike Dunlavey

6

Itu tergantung pada tahap pengembangan Anda, ketika awalnya mulai menulis sesuatu, optimasi mikro tidak boleh menjadi pertimbangan karena Anda akan mendapatkan lebih banyak keuntungan kinerja dengan menggunakan algoritma yang baik daripada Anda dengan menggunakan optimasi mikro. Juga, pertimbangkan apa yang Anda kembangkan karena aplikasi yang sensitif terhadap waktu akan melihat lebih banyak manfaat dari pertimbangan optimasi mikro daripada aplikasi bisnis umum.

Jika Anda menguji dan memperluas perangkat lunak maka optimasi mikro kemungkinan akan merugikan Anda, mereka cenderung membuat kode lebih sulit untuk dibaca dan bahkan memperkenalkan serangkaian bug unik mereka sendiri yang perlu diperbaiki bersama dengan hal lain yang perlu diperbaiki.

Jika Anda benar-benar mendapatkan keluhan dari pengguna tentang kode lambat maka mereka mungkin layak dipertimbangkan tetapi hanya jika semuanya telah diselesaikan, yaitu:

  • Apakah kodenya ditulis dengan baik?
  • Apakah aplikasi dapat mengakses datanya tanpa masalah?
  • Bisakah algoritma yang lebih baik digunakan?

Jika semua pertanyaan itu telah dijawab dan Anda masih memiliki masalah kinerja, maka mungkin sudah saatnya untuk mulai menggunakan optimasi mikro dalam kode, tetapi kemungkinan besar perubahan lain (mis. Kode yang lebih baik, algoritme yang lebih baik, dll.) Akan menjaring Anda lebih dari keuntungan kinerja daripada optimasi mikro.


5

Kecepatan eksekusi adalah salah satu dari banyak faktor yang berkontribusi pada kualitas program. Seringkali, kecepatan memiliki korelasi terbalik dengan keterbacaan / pemeliharaan. Dalam hampir semua kasus, kode harus dapat dibaca manusia sehingga kode tersebut dapat dipertahankan. Satu-satunya waktu yang dapat dibaca dapat dikompromikan adalah ketika kecepatan adalah persyaratan penting. Persyaratan untuk membuat kode lebih cepat daripada keterbacaan / pemeliharaan penuh memungkinkan hampir tidak pernah berlaku, tetapi ada beberapa kasus di mana ia akan melakukannya. Hal utama yang perlu diingat adalah bahwa kode yang dioptimalkan secara mikro sering kali berupa kode hacky, jadi kecuali ada persyaratan yang ditentukan di suatu tempat, hampir selalu merupakan cara yang salah untuk menyelesaikan masalah. Misalnya, pengguna hampir tidak akan pernah melihat perbedaan antara waktu eksekusi 0,5 detik dan 1 detik dalam operasi CRUD, jadi Anda tidak perlu masuk ke assembly-interop-hackfest untuk mencapai 0,5 detik. Ya, saya bisa menerbangkan helikopter ke tempat kerja dan itu akan menjadi 10 kali lebih cepat, tetapi saya tidak melakukannya karena harga dan fakta bahwa helikopter jauh lebih sulit untuk terbang.Ketika Anda mengoptimalkan mikro kode, ini adalah apa yang Anda lakukan: menambah kerumitan dan biaya yang tidak perlu untuk mencapai tujuan yang berlebihan.


5

Optimalisasi mikro penting ketika Anda mencapai batasan. Hal yang Anda pedulikan mungkin memori, mungkin throughput, mungkin latensi, atau mungkin konsumsi daya. Perhatikan bahwa ini adalah karakteristik tingkat sistem; Anda tidak perlu (dan tidak bisa) mengoptimalkan setiap fungsi dengan segala cara.

Sistem tertanam lebih cenderung membutuhkan optimasi mikro karena kendala lebih mudah dipukul. Namun, bahkan di sana mikro-optimasi hanya membuat Anda sejauh ini; Anda tidak dapat mengoptimalkan secara mikro jalan keluar dari desain yang buruk. Poin tentang desain yang baik dalam suatu sistem adalah bahwa Anda dapat mempertimbangkan sistem secara keseluruhan. Komponen yang membutuhkan optimasi mikro harus diekspos dengan rapi dan dioptimalkan dengan cara yang tidak mengganggu desain sistem.

Perhatikan bahwa sistem "tertanam" kecil hari ini bisa sangat dekat dengan Vaxen atau PDP-11 sebelumnya , jadi masalah ini dulunya lebih umum. Pada sistem tujuan umum modern yang melakukan komputasi komersial umum modern, optimasi mikro jarang terjadi. Ini mungkin bagian dari mengapa ayahmu mengambil posisi seperti itu.

Namun, tidak masalah apakah Anda berurusan dengan nanodetik, milidetik, detik atau jam; masalahnya sama. Mereka harus dievaluasi dalam konteks sistem dan apa yang ingin Anda capai.

Ini adalah contoh dari pertanyaan terakhir yang saya jawab di Stack Overflow untuk kasus di mana mikro-optimasi diperlukan: Enkoder video open source untuk sistem tertanam .


4

Masalah terbesar dengan mikro-optimasi adalah itu membuat Anda menulis kode lebih sulit untuk dipelihara.

Masalah lainnya adalah tergantung pada konfigurasi komputer, kadang-kadang optimasi mikro Anda mungkin memiliki kinerja terburuk daripada tanpa 'optimasi'.

Membuat banyak optimasi mikro akan menghabiskan banyak waktu Anda melawan sesuatu yang tidak terlalu penting.

Pendekatan yang lebih baik adalah dengan membuat kode yang lebih bersih, lebih mudah dipelihara, dan jika Anda mendapatkan masalah kinerja Anda menjalankan profil untuk mencari tahu apa yang sebenarnya membuat kode Anda lambat. Dan mengetahui persis apa yang benar-benar buruk Anda dapat memperbaikinya.

Saya tidak mengatakan bahwa tidak melakukan optimasi mikro adalah alasan untuk menulis kode bodoh.


4

Jika Anda mulai khawatir tentang milidetik, Anda harus mempertimbangkan untuk menyerah PHP dan menggunakan C atau Majelis sebagai gantinya. Bukannya saya ingin melakukan ini, tidak masuk akal untuk membahas angka-angka seperti itu dan menggunakan bahasa scripting. Apakah kode Anda berulang kali dengan perintah ini?

Faktor-faktor lingkungan di luar pertanyaan di sini, server-server itu menjalankan 24/7 dan jika mereka benar-benar memproses sesuatu hanya akan berarti jika itu benar-benar tugas yang berjalan untuk waktu yang sangat lama.

Kemungkinan besar cahaya di kantor Anda dan energi yang digunakan komputer kami saat kami mengetik pertanyaan dan jawaban, menghabiskan lebih banyak energi daripada jenis optimasi mikro apa pun yang dapat Anda aplikasikan secara wajar pada aplikasi yang akan disimpan.


+1 mematikan lampu atau tidak menjawab pertanyaan.
Boz

4

Anda harus memilih algoritma yang terbaik dan sederhana untuk tugas tersebut. Alasannya harus sederhana adalah agar kode dapat dibaca. Alasan itu perlu menjadi yang terbaik, adalah untuk menghindari memulai dengan karakteristik runtime yang buruk. Jangan membabi buta memilih BubbleSort ketika Anda tahu bahwa Anda akan memiliki kumpulan data yang besar. Namun, itu baik untuk jenis 10 elemen sesekali.

LALU, jika angka profil menunjukkan bahwa pilihan Anda yang terbaik, algoritma sederhana tidak cukup baik, Anda dapat memulai optimasi (yang biasanya sebagai biaya keterbacaan).


BubbleSort sebenarnya bisa lebih baik daripada quicksort atau mergesort ketika data Anda hampir diurutkan dengan hanya beberapa elemen liar yang tidak terlalu jauh dari tujuan akhir mereka. Namun untuk semua tugas lain, Anda harus menggunakan fungsi penyortiran bawaan yang disediakan oleh bahasa pemrograman Anda untuk Anda; ini adalah cara paling sederhana untuk memulai (dan fungsi sortir bawaan di sebagian besar bahasa memiliki kinerja yang baik). SARAN BURUK:, start out with bad runtime characteristicjangan sengaja memulai dengan karakteristik runtime yang buruk.
Lie Ryan

@ Lie, jika Anda TAHU bahwa data Anda hampir diurutkan dan Anda OLEH KARENA ITU dapat menggunakan bubblesort, Anda tidak sepenuhnya membabi buta memilih algoritma Anda ... Juga terima kasih telah menunjukkan kesalahan ketik.

4

Saya sudah mengatakannya sebelumnya, dan saya akan mengatakannya di sini: "Optimalisasi prematur adalah akar dari semua kejahatan" . Ini harus menjadi salah satu aturan di pusat pikiran setiap programmer.

Kode dapat, pada suatu titik, selalu lebih cepat daripada saat ini. Kecuali jika Anda mengemas perakitan tangan dengan chip tertentu, selalu ada sesuatu yang bisa diperoleh melalui optimasi. Namun, kecuali Anda INGIN menjadi rakitan pengemasan tangan untuk semua yang Anda lakukan, harus ada tujuan kuantitatif, yang setelah Anda temui, Anda mengatakan "itu cukup" dan berhenti mengoptimalkan, bahkan jika masih ada yang menatap tajam pengisap kinerja. Anda di wajah.

Kode cantik, elegan, sangat berkinerja tidak berguna jika tidak bekerja (dan dengan "kerja" maksud saya menghasilkan output yang diharapkan dengan semua input yang diharapkan). Oleh karena itu, menghasilkan kode yang berfungsi SELALU menjadi prioritas pertama. Setelah berhasil, Anda mengevaluasi kinerja, dan jika kurang, Anda mencari cara untuk membuatnya lebih baik, sampai pada titik di mana itu cukup baik.

Ada beberapa hal yang harus Anda putuskan di muka yang akan memengaruhi kinerja; keputusan yang sangat mendasar seperti bahasa / runtime yang akan Anda gunakan untuk mengimplementasikan solusi ini. Banyak dari ini akan mempengaruhi kinerja oleh banyak pesanan lebih dari memanggil satu metode vs yang lain. Sejujurnya, PHP, sebagai bahasa skrip, sudah menjadi hit kinerja, tetapi karena sangat sedikit situs skrip yang dibangun dari bawah ke atas dalam C / C ++, ini sebanding dengan teknologi lain yang kemungkinan akan Anda pilih (Java Servlets, ASP.NET , dll).

Setelah itu, ukuran pesan I / O adalah pembunuh kinerja terbesar Anda berikutnya. Mengoptimalkan apa yang Anda baca dari dan menulis ke hard disk, port serial, pipa jaringan, dll biasanya akan meningkatkan waktu menjalankan program dengan banyak urutan besarnya bahkan jika algoritma di balik operasi I / O efisien. Setelah itu, kurangi kompleksitas Big-O dari algoritme itu sendiri, dan kemudian jika benar-benar harus, Anda dapat "mengoptimalkan mikro" dengan memilih pemanggilan metode yang lebih murah dan membuat keputusan esoterik lainnya pada level rendah.


2
+1 Memproduksi kode yang berfungsi harus SELALU menjadi prioritas pertama.
Boz

2
@Keith, sebenarnya Knuth mengatakannya terlebih dahulu, dan dia mengatakan lebih dari itu.

"Buat itu bekerja, lalu buat itu bekerja secepat yang dibutuhkan untuk bekerja", Anon.
John Saunders

1
Sebenarnya agama adalah akar dari semua kejahatan, tetapi saya ngelantur.
Thomas Eding

4

Anda menyebutkan bahwa ayah Anda adalah pensiunan programmer. Programmer yang bekerja di dunia mainframe harus sangat memperhatikan kinerja. Saya ingat mempelajari aktivitas US Navy di mana mainframe mereka dibatasi oleh perangkat keras hingga 64 KB memori per pengguna. Di dunia pemrograman itu Anda harus mencari tahu setiap hal kecil yang Anda bisa.

Banyak hal yang sangat berbeda sekarang dan kebanyakan programmer tidak perlu terlalu khawatir tentang optimasi mikro. Namun, pemrogram sistem tertanam masih melakukan dan basis data orang masih sangat perlu menggunakan kode yang dioptimalkan.


3

Kode harus ditulis agar benar-benar jelas tentang apa yang dilakukannya. Kemudian, jika dan hanya jika terlalu lambat, kembalilah dan percepat. Kode selalu dapat diubah menjadi lebih cepat nanti, jika dapat dipahami - tetapi semoga berhasil mengubahnya menjadi jelas jika cepat.


3

Penting jika:

1) Kehidupan seseorang tergantung pada kode Anda. Fungsi yang membutuhkan waktu 25 ms untuk dijalankan di monitor detak jantung seseorang mungkin adalah ide yang buruk.

Saya pribadi mengambil pendekatan dua cabang - ada optimasi mikro yang dapat Anda lakukan yang tidak akan mempengaruhi keterbacaan - jelas Anda ingin menggunakannya. Tetapi jika itu mempengaruhi keterbacaan, tahan - Anda tidak akan mendapatkan banyak manfaat dan itu mungkin akan membawa Anda lebih lama untuk debug dalam jangka panjang.


2
Hanya beberapa poin kecil pada contoh Anda: Fungsi pada monitor detak jantung yang membutuhkan waktu 25 ms tidak akan menjadi masalah selama tugas-tugas lain yang diperlukan dapat terjadi dengan waktu respons yang diperlukan. Interupsi bagus untuk ini. Dan 25 ms latensi untuk sesuatu yang hanya memonitor peristiwa dunia nyata untuk memperbarui tampilan untuk konsumsi manusia mungkin bukan masalah.
janm

3

Apakah pengoptimalan mikro penting saat pengkodean?

Tidak, mengingat bahwa ada platform seperti JVM dan .NET di mana kode ditulis untuk mesin virtual dan dengan demikian mencoba untuk mengoptimalkan eksekusi mungkin tidak berjalan dengan baik karena apa yang optimal pada desktop pengembang tidak selalu sama pada server. Lihatlah seberapa jauh dihapus dari perangkat keras beberapa perangkat lunak tingkat tinggi ini untuk poin lain di sini. Sesuatu yang perlu dipertimbangkan adalah keberagaman perangkat keras, seberapa realistiskah untuk mengoptimalkan kode untuk chip tertentu seperti CPU atau GPU ketika model baru mungkin akan keluar dalam waktu kurang dari satu tahun?

Pertanyaan lain yang perlu dipertimbangkan adalah kinerja yang diukur dengan metrik apa: Kecepatan eksekusi, memori yang digunakan dalam eksekusi, kecepatan pengembangan fitur baru, ukuran basis kode pada server dalam bentuk yang dikompilasi atau tidak dikompilasi, skalabilitas, rawatan, dll. .? Jika diambil cukup luas, pertanyaannya menjadi sepele, tetapi saya tidak yakin seberapa luas Anda bermaksud untuk mengambil kinerja yang benar-benar dapat hampir apa saja asalkan dapat diukur dengan cara tertentu.


Beberapa optimasi mikro dapat berfungsi dan beberapa mungkin tidak berfungsi di mana orang dapat bertanya-tanya seberapa berharganya melakukan pekerjaan seperti itu dibandingkan dengan pekerjaan lain yang mungkin dilihat sebagai prioritas yang lebih tinggi seperti fitur baru atau memperbaiki bug. Pertanyaan lainnya adalah apakah upgrade perangkat keras atau perangkat lunak dapat merusak beberapa optimasi tersebut juga.


1
Perhatikan bahwa Anda benar-benar dapat melakukan optimasi mikro pada platform seperti JVM dan .NET, mereka hanya mengambil bentuk yang sedikit berbeda. Tetapi hal yang sama berlaku jika Anda membandingkan dan tua, kompiler C sederhana dengan kompiler yang lebih modern dan sangat mengoptimalkan: optimasi yang dapat dilakukan pengguna akan terlihat berbeda.
Joachim Sauer

1

Saya pikir ada perbedaan besar antara pemrograman yang bagus dan optimasi mikro.

Jika ada dua cara untuk melakukan tugas yang sama, yang satu lebih cepat dari yang lain dan keduanya memiliki keterbacaan yang sama, Anda harus menggunakan yang lebih cepat. Selalu. Dan ini pemrograman yang bagus. Tidak ada alasan untuk tidak menggunakan algoritma yang lebih baik untuk menyelesaikan masalah. Dan bahkan mendokumentasikannya pun mudah: berikan nama algoritme, semua orang akan dapat mencarinya di Google dan menemukan informasi lebih lanjut tentang cara kerjanya.

Dan algoritma yang baik sudah dioptimalkan. Mereka akan cepat. Mereka akan menjadi kecil. Mereka akan menggunakan memori minimum yang diperlukan.

Sekalipun menggunakannya, program Anda masih belum memiliki kinerja itu, mereka bisa Anda pertimbangkan untuk mengoptimalkannya secara mikro. Dan Anda harus benar-benar tahu bahasa untuk dapat mengoptimalkan mikro.

Dan selalu ada ruang untuk menghabiskan lebih banyak uang untuk perangkat keras. Perangkat keras itu murah, programmer mahal . Jangan menghabiskan terlalu banyak waktu / uang dengan mengoptimalkan ketika Anda hanya dapat membeli perangkat keras.


1

Pembacaan kode IMHO lebih penting daripada optimasi mikro karena dalam sebagian besar kasus optimasi mikro tidak sepadan.

Artikel tentang optimasi mikro yang tidak masuk akal :

Seperti kebanyakan dari kita, saya lelah membaca posting blog tentang optimisasi mikro yang tidak masuk akal seperti mengganti cetak dengan gema, ++ $ i oleh $ i ++, atau dua kali tanda kutip dengan satu tanda kutip. Mengapa? Karena 99,999999% waktu, itu tidak relevan. Mengapa? Karena 99,99% dari waktu, Anda sebaiknya menginstal akselerator PHP seperti APC, atau menambahkan indeks yang hilang ini di kolom basis data Anda, atau mencoba menghindari 1000 permintaan basis data yang Anda miliki di beranda.

cetak menggunakan satu lagi opcode karena sebenarnya mengembalikan sesuatu. Kita dapat menyimpulkan bahwa gema lebih cepat daripada cetak. Tapi satu opcode tidak ada biaya, benar-benar tidak ada.

Saya telah mencoba instalasi WordPress yang baru. Skrip berhenti sebelum diakhiri dengan "Bus Error" di laptop saya, tetapi jumlah opcode sudah lebih dari 2,3 juta. Cukup kata.

Jadi dalam kebanyakan kasus optimasi mikro menghemat 1 operasi di antara jutaan, tetapi membuat keterbacaan lebih buruk.


1

Jawaban lain benar tentang uang. Tapi saya akan menambahkan titik lain di mana kita harus membedakan apa optimasi prematur / optimasi mikro dan menulis kode performan yang mencerminkan pemahaman tentang perilaku konstruksi bahasa / kerangka kerja (maaf, tidak dapat menemukan satu kata untuk yang terakhir) . Yang terakhir adalah praktik pengkodean yang baik dan umumnya harus dilakukan!

Saya akan menjelaskan. Optimasi buruk (baca prematur / optimasi mikro) tidak ketika Anda mengoptimalkan bagian kode tanpa membuat profil untuk mengetahui apakah mereka benar-benar menjadi hambatan. Saat itulah Anda mengoptimalkan berdasarkan asumsi, desas-desus dan perilaku tidak berdokumen. Jika itu didokumentasikan dan melakukan sesuatu dengan cara yang lebih efisien / logis , betapapun kecilnya, saya menyebutnya optimasi yang baik . Seperti yang telah dinyatakan orang lain, keduanya memiliki kontra dan hampir tidak ada pro sama sekali sejauh Anda mendapatkan bisnis yang baik, tetapi saya tetap melakukan yang terakhir, bukan yang pertama, jika tidak sepenuhnya mengalahkan keterbacaan. Ya keterbacaan / rawatan sangat penting dan ini tentang di mana Anda menarik garis.

Saya akan mengulangi poin yang dibuat oleh orang lain di sini sebagai kesia-siaan dari optimisasi baik dan buruk:

  1. Ketergantungan Anda pada masalah tertentu dapat berubah dan waktu yang dihabiskan untuk mengoptimalkan sebelum menyelesaikan bagian logis dari aplikasi Anda adalah buang-buang waktu. Maksud saya mengoptimalkan pada tahap yang relatif awal. Hari ini Anda memiliki List<T>dan pada saat aplikasi Anda dikirimkan, Anda harus mengubahnya LinkedList<T>dan sekarang semua pembandingannya adalah buang-buang waktu dan usaha.

  2. Sebagian besar hambatan sebenarnya dari aplikasi Anda (baca sebagai perbedaan yang dapat diukur) bisa menjadi 5% dari kode Anda (kebanyakan yang sql) dan mengoptimalkan 95% lainnya tidak memberikan manfaat bagi pelanggan Anda.

  3. Biasanya "secara teknis" kode berkinerja lebih baik berarti lebih banyak verbositas yang pada gilirannya berarti lebih banyak kode rawan kesalahan yang pada gilirannya berarti pemeliharaan lebih keras dan lebih banyak waktu yang dihabiskan yang pada gilirannya berarti Anda menghasilkan lebih sedikit uang.

  4. Jejak karbon yang Anda hemat untuk seluruh dunia melalui perolehan kinerja 1% mudah dikerdilkan oleh gas rumah kaca yang harus dipancarkan oleh tim Anda saat debugging dan mempertahankan kode itu.

Negatif dari optimasi buruk khususnya adalah:

  1. Itu tidak sering memberi Anda kinerja yang Anda harapkan. Lihat pertanyaan ini di SO, di mana optimasi salah . Bahkan dapat memiliki efek buruk. Itulah masalah dengan perilaku tidak berdokumen.

  2. Kebanyakan kompiler modern akan melakukannya untuk Anda.

Saya akan memberikan beberapa contoh optimasi yang buruk dan baik:

Keburukan -

  1. menggunakan tipe integer yang lebih kecil sebagai ganti Int32.

  2. ++i digunakan sebagai ganti i++

  3. forbukannya foreach(yang terburuk yang saya lihat, benar-benar mengalahkan logika)

  4. menghindari variabel tertutup

    string p;
    foreach (var item in collection)
        p = ...;
    
  5. menggunakan charalih-alih string selama penggabungan string, seperti:

    string me = 'i' + "me myself"; // something along that line - causes boxing
    

Yang baik (dari dunia .NET. Harus jelas) -

  1. Pencarian ganda

    if (Dictionary<K, V>.TryGetValue(K, out V))
        do something with V
    

    dari pada

    if (Dictionary<K, V>.ContainsKey(K))
        do something with Dictionary<K, V>[K]
    
  2. Muat semuanya

    DirectoryInfo.EnumerateFiles();
    

    dari pada

    DirectoryInfo.GetFiles();
    
  3. Dua tahap casting:

    s = o as string;
    if (s != null)
        proceed
    

    dari pada

    if (o is string)
        s = (string)o;
    
  4. Jika pesanan tidak masalah

    if (counter < X || expensiveFunction())
    

    dari pada

    if (expensiveFunction() || counter < X)
    
  5. Tinju

    void M<T>(T o) //avoids boxing
    {
    
    }
    

    dari pada

    void M(object o)
    {
    
    }
    

Jika Anda bertanya kepada saya apakah ini memberikan manfaat kinerja yang nyata, saya akan mengatakan tidak. Tetapi saya akan menyarankan seseorang harus menggunakannya karena itu berasal dari pemahaman tentang perilaku konstruksi ini. Mengapa melakukan dua panggilan saat Anda bisa melakukan 1 saja? Dari sudut pandang filosofis praktik pengkodean yang baik. Dan 1 & 3 juga sedikit kurang dapat dibaca dalam istilah yang ketat, tetapi apakah mereka melampaui keterbacaan? Tidak, tidak banyak, jadi saya gunakan. Nah, itulah kuncinya - mempertahankan rasio kinerja yang layak untuk dibaca. Dan ketika itu, tentang di mana Anda menarik garis.


1

"Layak" membutuhkan konteks, seperti seberapa sederhana menulis dan membaca dan memelihara vs seberapa cepat membuat sesuatu bagi pengguna nyata lebih responsif, interaktif, membutuhkan lebih sedikit waktu bagi mereka untuk menunggu.

Menyimpan beberapa sen untuk membeli sekaleng soda tidak akan banyak gunanya bagiku jika aku harus menempuh perjalanan jauh untuk menghemat uang itu, terutama mengingat aku jarang minum soda akhir-akhir ini. Menyimpan beberapa sen per kaleng untuk pembelian satu juta kaleng soda bisa menjadi masalah besar.

Sementara itu menyimpan beberapa uang ketika dua orang tepat di sebelah saya dan satu menawarkan hal yang sama persis untuk beberapa uang lebih murah dan yang lainnya tidak, dan saya memilih yang lebih mahal karena saya suka topi mereka lebih baik seperti kasus bodoh pesimisasi.

Apa yang sering saya temukan orang-orang sebut "optimasi mikro" tampaknya aneh tanpa pengukuran, dan konteks, dan diskusi pengguna-akhir, ketika harus benar-benar ada ketiganya untuk mempertimbangkan optimasi seperti itu jika mereka tidak sepele untuk diterapkan. Bagi saya optimasi mikro yang tepat akhir-akhir ini berhubungan dengan hal-hal seperti tata letak memori dan pola akses, dan meskipun mereka mungkin tampak "mikro" dalam fokus, mereka tidak berpengaruh mikro.

Saya berhasil, belum lama ini, mengurangi operasi turun dari 24 detik menjadi 25 milidetik (sekitar 960 kali lebih cepat), dengan output yang identik (dijamin dengan tes otomatis), tanpa perubahan kompleksitas algoritmik, untuk pengerasan difusi panas volumetrik, melalui "mikro-optimasi" (yang terbesar berasal dari perubahan tata letak memori yang turun menjadi sekitar 2 detik, kemudian sisanya adalah hal-hal seperti SIMD dan analisis lebih lanjut dari cache cache di VTune dan beberapa pengaturan tata letak memori lebih lanjut).

Wolfire menjelaskan tekniknya di sini, dan dia berjuang dengan waktu yang diperlukan: http://blog.wolfire.com/2009/11/volumetric-heat-diffusion-skinning/

Implementasi saya berhasil melakukannya dalam milidetik ketika ia berjuang untuk menurunkannya menjadi kurang dari satu menit: masukkan deskripsi gambar di sini

Setelah saya "mengoptimalkan mikro" dari 24 detik menjadi 25 ms, itu adalah game-changer dalam alur kerja. Sekarang seniman dapat mengubah rig mereka secara realtime di lebih dari 30 FPS tanpa menunggu 24 detik setiap kali mereka membuat sedikit perubahan pada rig mereka. Dan itu benar-benar mengubah seluruh desain perangkat lunak saya karena saya tidak lagi memerlukan progress bar dan hal-hal semacam ini, semuanya menjadi interaktif. Jadi itu mungkin "mikro-optimasi" dalam arti bahwa semua perbaikan datang tanpa peningkatan kompleksitas algoritmik, tetapi itu adalah "mega-optimasi" yang berlaku yang membuat apa yang sebelumnya merupakan proses menyakitkan, non-interaktif menjadi realtime, interaktif yang benar-benar mengubah cara pengguna bekerja.

Pengukuran, Persyaratan Pengguna-Akhir, Konteks

Saya benar-benar menyukai komentar Robert di sini dan mungkin saya gagal menyampaikan maksud yang saya inginkan:

Baiklah, ayolah. Tidak ada yang akan berpendapat bahwa perubahan semacam ini tidak "sepadan." Anda dapat menunjukkan manfaat nyata; banyak yang disebut optimasi mikro tidak bisa.

Ini, meskipun bekerja di bidang yang sangat kritis terhadap kinerja dengan persyaratan waktu-nyata yang sering, satu-satunya waktu saya mempertimbangkan setiap optimasi mikro yang mengharuskan keluar dari jalan saya.

Dan saya menekankan bukan hanya pengukuran tetapi sisi pengguna. Saya orang aneh karena saya datang ke bidang saya saat ini (dan sebelumnya gamedev) sebagai pengguna / penggemar pertama, pengembang kedua. Jadi saya tidak pernah begitu bersemangat dengan hal-hal biasa yang membuat para programmer senang memecahkan teka-teki teknis; Saya menemukan mereka beban, tetapi akan menanggungnya melalui mimpi pengguna akhir yang saya bagikan dengan pengguna lain. Tapi itu membantu saya memastikan jika saya mengoptimalkan sesuatu, itu akan berdampak nyata pada pengguna dengan manfaat nyata. Ini adalah perlindungan saya terhadap pengoptimalan mikro tanpa tujuan.

Itu sebenarnya sama pentingnya dengan profiler dalam pendapat saya, karena saya memiliki rekan yang melakukan hal-hal seperti subdivisi mengoptimalkan mikro kubus menjadi satu miliar aspek hanya untuk tersedak model produksi dunia nyata seperti karakter dan kendaraan. Hasilnya sangat mengesankan dalam arti "demo teknologi", tetapi hampir tidak berguna bagi pengguna yang sebenarnya, karena mereka membuat profil dan mengukur dan membandingkan kasus yang tidak selaras dengan kasus penggunaan di dunia nyata. Jadi, sangat penting untuk memahami apa yang penting bagi pengguna terlebih dahulu, baik dengan belajar berpikir dan menggunakan perangkat lunak seperti itu atau berkolaborasi dengan mereka (idealnya keduanya, tetapi setidaknya berkolaborasi dengan mereka).


2
Baiklah, ayolah. Tidak ada yang akan berpendapat bahwa perubahan semacam ini tidak "sepadan." Anda dapat menunjukkan manfaat nyata; banyak yang disebut optimasi mikro tidak bisa.
Robert Harvey

1
@RobertHarvey Itu semacam titik saya berharap untuk membuat, karena apa yang beberapa orang menyebutnya "mikro-optimasi" belum tentu mikroskopis berlaku, tapi begitu tergantung pada konteks, pengukuran, dll issetvs strlentampaknya lebih kecil dalam fokus tidak ada konteks dan pengukuran. :-D
Dragon Energy

1
@RobertHarvey Saya berharap untuk mengatakan, mungkin meskipun secara tidak langsung, bahwa jika ada konteks negatif untuk "optimasi mikro", itu adalah jenis yang cenderung tanpa pengukuran, konteks, dan kebutuhan pengguna akhir. Saya dapat melanjutkan tentang kasus terakhir juga karena saya memiliki seorang kolega yang mengoptimalkan neraka dari sesuatu yang keren, kecuali tidak ada yang menggunakannya. Saya bahkan berpikir optimalisasi yang tepat membutuhkan pemahaman pengguna akhir, jika tidak kita bisa membuat profil dan menyetel hal-hal yang tidak dipedulikan pengguna.
Dragon Energy

1
Beberapa optimisasi didorong oleh kebutuhan yang mendesak, sementara yang lain didorong oleh rasa ingin tahu (pengejaran intelektual dan petualangan). Kami membutuhkan keduanya. Dalam cerita Dragon Energy, itu mungkin bukan "kebutuhan mendesak", karena artis tampaknya tidak mengeluh dengan keras tentang tidak melihat hasil rendering sampai 24 detik setelah setiap pengeditan. Bahkan, pengguna mungkin tidak tahu seberapa cepat itu bisa terjadi, sampai seorang programmer berinvestasi dalam semua upaya untuk mengalahkan rekor kecepatan. Membatasi diri kita sendiri pada permintaan yang didorong masuk akal secara bisnis, tetapi melakukan hal itu akan kehilangan beberapa peluang optimasi atau pengubah permainan yang menakjubkan.
rwong

1
Berbicara tentang naluri bisnis, ada juga masalah monetisasi. Setiap langkah (mis. Seorang programmer yang bekerja pada pengoptimalan kinerja) membutuhkan uang, dan biaya itu perlu diganti agar masuk akal secara bisnis. Dengan demikian, kita harus bertanya apakah peningkatan kecepatan perubahan-game dapat "dijual", atau berapa banyak uang yang akan "dihemat", jika programmer harus mendapatkan persetujuan dari manajer bisnis.
rwong

0

Saya akan begini - optimasi mikro adalah proses mengoptimalkan sesuatu yang bukan hambatan sama sekali. Misalnya, jika program Anda memanggil dua fungsi A dan B, dan A membutuhkan 100 milidetik untuk menyelesaikan dan B membutuhkan 2 mikrodetik, dan Anda terus mengoptimalkan fungsi B. Itu tidak hanya tidak penting, itu juga salah. Tetapi mengoptimalkan fungsi B disebut optimasi dan bukan optimasi mikro. Pentingnya optimasi tergantung. Katakanlah Anda tidak memiliki hal lain untuk dilakukan dan program Anda bebas bug, maka ya, itu penting. Tetapi umumnya Anda memiliki prioritas. Katakanlah Anda perlu menambahkan / menulis fungsi C. Jika Anda berpikir bahwa fungsi menulis C akan membuat Anda lebih banyak uang daripada membuat program Anda lebih cepat tanpa fungsi itu, maka lakukan optimasi. Kalau tidak mengejar fungsionalitas. Juga, pemrogram berpengalaman yang berfokus pada kinerja tidak menghabiskan banyak waktu untuk mengoptimalkan, mereka hanya menulis program cepat. Setidaknya mereka tahu alat apa yang digunakan dan apa yang tidak boleh menghabiskan waktu bertahun-tahun melakukan optimisasi yang tidak berarti (baca mikro).


posting ini agak sulit dibaca (dinding teks). Maukah Anda mengeditnya menjadi bentuk yang lebih baik?
nyamuk
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.