Btw jangan confuse "compiler" here as java/c# sebagai IL/bytecode compiler. Compiler disini mostly refers to JIT compiler
2010/5/28 Hendry Luk <hendrym...@gmail.com> > Agak susah googlenya, tapi ini contoh yg gw dapet dari quick google: > http://blogs.msdn.com/b/brada/archive/2005/04/23/411321.aspx > > In this case, itu adalah array. Tapi nothing is stopping them buat erase > out-of-bound checking as long as lu pake pake framework classes mereka > (List, ArrayList, Hashmap, Tables etc), ato even your own derived classes > yang gak override default Count() behavior. Optimisation bisa at compile > time maupun at runtime. > Contoh laen adalah if-else block. Kalo method lu ada if-else dalam sebuah > method berdasarkan parameter condition tertentu, compiler lu kadang bakal > produce 2 (or more) separate methods, each one buat handle kondisi parameter > tertentu (jika kondisi ini bisa diderive at compile/JIT time), jadi if-else > block lu bakal completely dihapus. Hence, at runtime, if-else statement lu > gak pernah diexecute sama sekali. > Ini adalah the fundamental difference between managed code dan unmanaged. > Di managed code, what you see isnt necessarily what you get. > > Intinya adalah, use framework classes the way they're intended to be used, > instead of pake clever MacGyver tricks buat outsmart the framework, karna > chances are, framework designer lu udah meng-optimise specifically for > "common usage pattern". Jadi ikutin ajah the recommended usage pattern, gak > perlu think too hard buat optimise pake strange way. > > 2010/5/28 Jecki <jecki...@gmail.com> > > >> >> 2010/5/27 Hendry Luk <hendrym...@gmail.com <hendrymail%40gmail.com>> >> >> > >> > Gak tau kalo di java.. tapi di .net cara 1 lebih efisien. >> > >> > First of all, kalo lu akses array/list pake cara 1, compiler gak bakal >> produce loop block yang terus2an manggil Count() di tiap iteration, >> melainkan bakal pake temporary variable, exactly the same kayak kalo lu >> tulis pake cara 2. Jadi lu gak gain anything dengan nulis pake cara 2. >> > >> >> Gw gak ngerti .NET, tapi rasanya ada yang janggal sama statement ini. >> Bisa kasih reference? >> >> Kalau itu adalah array maka masih ada kemungkinan karena sifat array >> yang immutable dan merupakan language construct yang out of the shelf >> di-support oleh programming language, dalam arti sangat mungkin >> mendapat perlakuan khusus. >> >> Kalau itu adalah List maka kemungkinannya berkurang karena List itu >> hanya interface dan implementasinya bisa macem-macem. Berarti si >> compiler musti tau implementasi List apa yang lagi dipakai, kemudian >> analisa apakah misalnya list.size() dari implementasi tersebut tidak >> melakukan perubahan yang menyebabkan pemanggilan list.size() >> berikutnya berubah nilainya. Kalau compiler dengan seenaknya >> mengasumsi bahwa list.size() cukup dipanggil sekali dan mengubah logic >> program dari cara 1 ke cara 2 (seperti yang di-post oleh TS) betapa >> ngerinya itu karena optimization yang dilakukan malah mengubah logic >> program. Kalau sampai ini terjadi sih berarti "This compiler >> optimization is root of all evil". >> >> Setau saya yang namanya block program: >> >> for (<initial value>:<condition>:<incrementor>) { >> } >> >> itu bagian <condition> akan dipanggil setiap kali perulangan loop >> terjadi. Bahkan kelebihan sekali. Coba contoh kode berikut: >> >> [code] >> public class App { >> public static void main(String[] args) { >> int[] arr = new int[]{1, 2, 3, 4, 5}; >> for (int i = 0; i < getSize(arr); i++) { >> // do nothing >> } >> } >> >> public static int getSize(int[] arr) { >> System.out.println("You've just called getSize(int[])"); >> return arr.length; >> } >> } >> [/code] >> >> itu akan print "You've just called getSize(int[])" sebanyak 6 kali, >> atau N+1. Kalau ada compiler yang mencoba optimasi dan nge-print >> "You've just called getSize(int[])" sekali doang then that compiler is >> totally a crap. Compiler optimization should not change program's >> logic. >> >> Ya ya ini ga signifikan. Cuma dipanggil 6 kali dan mungkin bedanya >> cuma 2 CPU cycle tiap kali pemanggilan. But if you're processing in >> bulk this might you more time. >> >> Intinya ga cuma masalah performance tapi sebagai developer musti tau >> yang mana yang optimized. Ya memang kita bukan selevel tukang bikin >> compiler. Tapi tau cara2 optimasi primitif (primitif di sini maksudnya >> pake mata aja uda keliatan kalo yang satu lebih cepet dari yang laen) >> kan ga ada salahnya. Biarlah developer compiler yang mikirin optimasi >> yang njelimet dan perlu analisa yang lebih dalam. >> >> >> > Second of all, lu mesti tau bahwa saat lu akses content dari array ato >> list, ada routine di runtime buat ngecek apakah lu berusaha ngakses index >> yang di luar array/list tersebut, in which case lu bakal dapet >> IndexOutOfBoundException. >> > >> > Kalo lu tulis pake cara 1, compiler lu bakal conclude bahwa code block >> lu dah safe, sehingga compiler bakal optimise the code dengan erase routine >> yang anticipates index-out-of-bound situation. Hasilnya, gak cuma lu dapet >> compiled code yang sama dengan cara 2, tapi juga code lu dioptimised dengan >> ngebuang routine2 yang gak applicable dengan situasi lu. >> > >> >> Ya di java juga ada pengecekan IndexOutOfBoundException. Tapi bisa >> sertakan reference kalau pengecekan IndexOutOfBoundException akan >> di-skip kalau pake cara 1? >> >> Kalau untuk array sekali lagi sangat besar kemungkinannya compiler >> melakukan optimization seperti itu. Tapi kalau untuk List (yang >> implementasinya bisa macem-macem) koq rasa-rasanya kemungkinannya >> kecil ya? >> >> >> > Foreach syntax, for(xx: list), is even better. >> > >> >> Bisa jadi, terutama untuk tipe data array. Mungkin ada yang bisa >> berikan pembuktian di sini? >> >> >> > Again, gw gak tau di java, all those are true in .net. >> > Tapi moral of this story adalah, jangan try too hard buat optimise your >> code dengan ngeja word-by-word pake smart fine-tuned instructions. Compiler >> dan jdk ditulis oleh very very smart people, dan sangat jarang lu bisa nulis >> java code yang outsmarts them. Most of the time optimisation attempt lu >> actually makes it worse. >> > Modern language increasingly ngasih more and more syntatic sugars yang >> bikin code lu makin high-level dan declarative (e.g. syntax kayak for-each, >> closure, Linq, Parallel/PLinq, dynamic, auto-property, etc), tujuannya >> *bukan* semata2 buat bikin programmers write less. Melainkan, language >> abstraction ini plays an important role buat ngasih penulis compiler enough >> flexibility buat produce optimised solution dari code lu. >> >> Agree. >> >> >> > Kalo lu bypass abstraction ini, dan lengsung terjun low-level nge-dikte >> code lu dengan specific instructions, lu justru gak ngasih compiler lu >> anymore room buat nyisipin any optimisation logic ke bytecode lu. >> > >> >> IMO Untuk kasus di atas tidak low level sama sekali. This is merely a >> simple fact that you can build as habit. >> >> >> > 2010/5/27 Jecki <jecki...@gmail.com <jecki.go%40gmail.com>> >> >> >> >> >> >> >> >> 2010/5/27 Niksen Harjanto >> >> <milis.java.ko...@gmail.com<milis.java.kodok%40gmail.com> >> > >> >> >> >> > >> >> > >> >> > >> >> > rekan2 saya mau tanya, diantara 2 statement looping ini, mana yang >> >> > lebih baik, alasan teknisnya kenapa? >> >> > >> >> > Mis saya punya JTable, mau dilooping untuk baca datanya. >> >> > >> >> > Cara 1 (cara yang simple) : >> >> > >> >> > int x; >> >> > for (x=0; x<table.getRowCount(); x++) { >> >> > bla bla bla >> >> > } >> >> > >> >> > Cara 2 (IMHO lebih efisen) : >> >> > >> >> > int x; >> >> > int y; >> >> > y = table.getRowCount(); >> >> > for (x=0; x<y; x++) { >> >> > bla bla bla >> >> > } >> >> > >> >> > Saya milih nomor 2 karena takutnya java selalu mengecek apa nilai x < >> >> > table.getRowCount(). Soalnya di dalem function getRowCount pasti ada >> >> > banyak statement untuk dapetin jumlah row, yang akan dieksekusi >> >> > terus2an selama looping. Sedang no 2, function getRowCount() cuma >> >> > dieksekusi 1x, trus nanti yang dibandingin cuma variable int dengan >> >> > variable int. >> >> > >> >> > bener ga sih analisa gw? >> >> > >> >> >> >> benul, alias benar-benar betul. >> >> >> >> bisa juga gini: >> >> >> >> for (int x=0, y = table.getRowCount(); x<y; x++) { >> >> // bla bla bla >> >> } >> >> >> >> biar tetep efisien dan scope dari variable tetep sekecil mungkin. >> >> >> >> > makasih >> >> > >> > >> >> > >
