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
> >> >
> >
>
>
