2010/5/28 Samuel Franklyn <sfrank...@gmail.com> > > > > > Ga perlu baca source code dari getRowCount juga udah ketauan kalau > > cara pertama itu cenderung lebih lelet, walaupun mungkin sangat kecil > > sekali. Kecuali compiler melakukan optimization. > > Betul lebih lambat akan tetapi lebih lambat berapa persen? > Kalau cuma lebih lambat 0.1 % apakah worthed kita menambahkan > baris code. Ingat tiap baris code artinya pertambahan effort > untuk memelihara aplikasi. >
Penambahan code 1 baris macam deklarasi variable juga ga berpengaruh banyak sama effort untuk memelihara aplikasi. Setuju kalau optimization jangan sampai membuat aplikasi susah di-maintain. Kasus di atas kan sebenarnya simple, sekali liat langsung tau. Kemudian bisa disarikan jadi best practice. Setelah itu secara otomatis tiap kali tulis code ikutin best practice. Tentunya best practice itu musti yang gampang dilakukan. Jangan yang njelimet dan error-prone. > > > > Terobsesi memang ada sisi baik dan buruknya. Tapi belajar memahami apa > > yang baik dan tidak itu tidak ada salahnya. Lama-lama juga bosen > > sendiri optimize hal2 seperti ini. Atau kalau sudah jadi habit malah > > ga kepikiran sama sekali tau-tau codingnya udah optimized. > > Memahami cara kerja library itu bagus. Tapi apa > yang dilakukan oleh Niksen adalah micro optimization. > Dari pengalaman gua micro optimization itu distract seseorang > dari the bigger picture. > OK gw ga tau context-nya dia tanya pertanyaan ini. Apakah untuk optimize code yang sudah ada, yang sudah running well? Atau sekedar mau tau yang mana yang lebih cepat, dan syukur2 dia mau coding kaya gitu ke depannya. Kalau untuk optimize code yang sudah ada sih betul ini micro optimization yang effort-nya mungkin ga akan sebanding dengan peningkatan performance yang akan didapat. Bayangin misal program dia sekarang ada 100 file source. Kemudian harus ubah code yang pattern-nya seperti ini di ke 100 source files tersebut, tapi peningkatan performance cuma misalnya 1%. Ini sama sekali ga worth it. Beda kalau dia mau tau yang mana yang lebih cepat. Sekarang kan dia uda tau tuh cara kedua memang lebih cepat. Setelah itu kalau mau coding ya mustinya tau yang mana yang musti dipilih. > > Ga ada salah sama statement Donald Knuth. Maksud dia baik. Jangan > > optimize terlalu dini. Jangan over optimize sesuatu yang belum tentu > > tidak optimized. > > > > Tapi di sisi lain ada orang yang tipenya ga mau tau soal optimasi sama > > sekali. Coding maen hajar bleh, terus berlindung di balik statement > > Donald Knuth "Premature optimization is the root of all evil". Sampai > > satu titik kita musti optimasi. Nah bingung deh kalo udah gini. > > Nggak pernah kejadian tuh sama gua. Pada saat gua butuh melakukan > optimisasi biasanya itu cuma perlu dilakukan di 1 atau 2 titik saja. > Itu karena gua fokus membuat aplikasi yang semodular mungkin. > Kalau ada bagian aplikasi yang lambat maka itu akan terkonsentrasi > di 1 atau 2 titik saja. > Yah beda lah kalau udah se-level Samuel. Gw percaya banget ama kemampuan lu. Tapi banyak org di luar sana yang coding WORA mirip slogan Java, tapi Write Once Run (far, far, far) Away, alias tabrak lari. Nah buat orang kaya gini nih musti diajarin nulis code secara manusiawi. > > > > Orang dulu bilang sedikit-sedikit lama-lama menjadi bukit. Kalo hanya > > ada 1 baris code yang tidak optimize seperti contoh di atas mungkin > > tidak terlalu banyak impact. Tapi kalau ada seribu baris seperti di > > atas, tersebar di ratusan source files, akhirnya mempengaruhi > > performance bukannya tambah repot. > > Ini juga pernyataan yang kelihatannya bagus akan tetapi > tidak benar dalam praktek. Dalam praktek yang sudah > saya tekuni selama belasan tahun maka saya temui yang namanya > bottle neck itu tidak pernah tersebar diberbagai tempat. > Seperti namanya bottle neck itu senantiasa terkonsentrasi > di 1 atau 2 titik saja. Performance yang tinggi itu bagi saya > adalah menghilangkan semua bottle neck dan memberikan > kesan aplikasi responsif kepada user. Kalau dalam aplikasi > tidak ada bottle neck maka begitu resource hardware atau > network dinaikkan maka aplikasi akan langsung naik performancenya. > Aplikasi yang senantiasa memberikan feed back ke user juga > memberikan kesan lebih cepat padahal adanya code untuk > feedback itu sebenarnya memperlambat kerja aplikasi. > Sekali lagi kasus micro optimization ga mungkin terjadi sama Samuel (please take that as a compliment) > > > > Intinya sih sebagai developer musti ngerti lah do's and don'ts > > programming dari berbagai aspek. Kalau tau hal2 kecil kaya gini bisa > > mempengaruhi performance (walaupun musti muncul beribu kali dulu baru > > berasa) ya lakukan dengan benar. > > > > Bedakan isu memahami cara kerja library dengan isu melakukan > micro optimization di mana-mana. Memahami cara kerja libray bagus dan perlu. > Melakukan micro opt dimana-mana itu nggak bagus. Setuju, tapi ada tambahan. Micro optimization kalau: - effort-nya kecil - tidak mempengaruhi kemudahan maintenance aplikasi - sangat mudah dilakukan sebaiknya dijadikan habit. Kalau yang model nasi sudah menjadi bubur sih uda deh ga usah lakukan micro optimization. Fokus ke optimization yang menghasilkan peningkatan performance paling signifikan aja.
