Apa arti dari aturan 90/10 tentang optimasi program?


67

Menurut Wikipedia, aturan 90/10 tentang optimasi program menyatakan bahwa “90% dari waktu eksekusi program dihabiskan untuk mengeksekusi 10% dari kode” (lihat paragraf kedua di sini ).

Saya benar-benar tidak mengerti ini. Apa sebenarnya artinya ini? Bagaimana 90% waktu eksekusi dapat dihabiskan hanya mengeksekusi 10% dari kode? Bagaimana dengan 90% kode lainnya? Bagaimana mereka dapat dieksekusi hanya dalam 10% dari waktu?


50
Beberapa bagian dari kode dapat dieksekusi lebih sering daripada bagian lain. Lagipula, itulah gunanya loop. Dalam prakteknya, hampir selalu beberapa bagian yang dieksekusi dengan cara lebih sering daripada yang lain.
Kilian Foth

147
Tunggu hingga Anda mendengar aturan 90/10 untuk durasi proyek perangkat lunak: “90% dari proyek akan mengambil 90% pertama dari waktu yang diberikan; 10% terakhir dari proyek akan mengambil 90% dari waktu yang diberikan ”.
Paul D. Waite

3
Kebingungan di sini: "waktu dihabiskan untuk mengeksekusi". Pertimbangkan a++; for(i=0;i<100;i++){b++;} for(i=0;i<100;i++){print(xyz);}. Tentu for-loop pertama menghabiskan lebih banyak daripada pernyataan pertama, tetapi for-loop kedua menghabiskan ~ 1000x lebih banyak waktu daripada for-loop pertama, tetapi tidak mengeksekusi . Menghabiskannya menunggu cetak . Jadi ada perbedaan antara waktu yang dihabiskan untuk eksekusi , dan waktu kode bertanggung jawab untuk itu .
Mike Dunlavey

32
@ Paul_D._Waite Saya pikir itu adalah bahwa 90% dari proyek mengambil 90% dari waktu, 90% dari apa yang tersisa membutuhkan 90% dari waktu, dan seterusnya seri non-konvergen ke kesimpulan bahwa tidak ada proyek pernah selesai atau sepenuhnya disadap dalam waktu kurang dari tak terbatas.
nigel222

9
Sebagai contoh praktis, beberapa kode yang saya kerjakan (model ilmiah) menggunakan sejumlah besar kode (~ 10K baris) untuk membaca dan mengatur model, kemudian melakukan loop melalui beberapa ratus baris untuk melakukan perhitungan yang sebenarnya. Tapi itu loop pendek adalah n ^ 4 (tiga dimensi ruang iterasi melalui ribuan langkah waktu), jadi butuh berhari-hari untuk menghitung. Jadi rasio aktual mungkin lebih seperti 99% / 1% :-)
jamesqf

Jawaban:


184

Ada dua prinsip dasar yang dimainkan di sini:

  • Beberapa kode dieksekusi lebih sering daripada kode lainnya. Misalnya, beberapa kode penanganan kesalahan mungkin tidak pernah digunakan. Beberapa kode akan dieksekusi hanya ketika Anda memulai program Anda. Kode lain akan dieksekusi berulang saat program Anda berjalan.
  • Beberapa kode membutuhkan waktu lebih lama untuk dijalankan daripada kode lainnya. Misalnya, satu baris yang menjalankan kueri pada database, atau menarik file dari internet mungkin akan memakan waktu lebih lama dari jutaan operasi matematika.

Aturan 90/10 tidak benar secara harfiah. Ini bervariasi berdasarkan program (dan saya ragu ada dasar untuk angka-angka spesifik 90 dan 10 sama sekali; seseorang mungkin menarik mereka keluar dari udara). Tetapi intinya adalah, jika Anda ingin program Anda berjalan lebih cepat, mungkin hanya sejumlah kecil baris yang signifikan untuk mewujudkannya. Mengidentifikasi bagian lambat dari perangkat lunak Anda seringkali merupakan bagian terbesar dari optimasi.

Ini adalah wawasan yang penting, dan itu berarti bahwa keputusan yang tampaknya berlawanan dengan pengembang baru seringkali benar. Sebagai contoh:

  • Ada banyak kode yang tidak sepadan dengan waktu Anda untuk membuat "lebih baik" , bahkan jika melakukan sesuatu dengan cara yang bodoh dan sederhana. Bisakah Anda menulis algoritma pencarian yang lebih efisien untuk aplikasi XYZ? Ya, tetapi sebenarnya perbandingan sederhana dari setiap nilai membutuhkan jumlah waktu yang sepele, meskipun ada ribuan nilai. Jadi itu tidak layak. Mungkin sulit bagi pengembang baru untuk menghindari optimasi yang tidak perlu, karena dalam program gelar mereka begitu banyak waktu dihabiskan untuk menulis algoritma "benar" (yang berarti paling efisien). Tetapi di dunia nyata, algoritma yang benar adalah yang bekerja dan berjalan cukup cepat.
  • Perubahan yang membuat kode Anda jauh lebih lama dan lebih kompleks mungkin masih menjadi kinerja menang. Misalnya, dalam aplikasi FOO mungkin perlu menambahkan ratusan baris logika baru, hanya untuk menghindari panggilan basis data tunggal.

6
Dari catatan khusus, dengan hal-hal seperti fungsi penyortiran, itu jauh lebih cepat (dalam waktu dev) dan lebih mudah untuk membuat algo sederhana bodoh melakukan hal yang benar dalam semua kasus daripada untuk mendapatkan algo elegan yang berfungsi penuh dan tanpa bug. (Satu-satunya alasan untuk menulis semacam algo di luar acadamea adalah jika Anda sedang membangun perpustakaan atau bekerja di platform tanpa satu ...)
StarWeaver

5
Saya pikir Anda perlu menambahkan tautan ke shouldioptimize.com :)
Ivan Kolmychek

13
Saya pikir 90/10 berasal dari Prinsip Pareto 80/20 yang terkenal en.wikipedia.org/wiki/Pareto_principle
fernando.reyes

2
@StarWeaver Itulah sebabnya bahasa yang membuat penulisan jenis yang sangat efisien semudah atau lebih mudah daripada jenis gelembung yang jelek sangat penting di sana, seperti C ++. Algoritma dan kode "prabackaged" seperti itu dapat benar-benar sangat dioptimalkan tanpa menyebabkan kerumitan pada saat digunakan.
Yakk

6
@IvanKolmychek Situs itu menyesatkan. Tentu, analisis biaya semacam itu adalah salah satu faktor yang perlu dipertimbangkan, tetapi ada faktor lain seperti pengalaman pengguna. Anda mungkin menghemat banyak uang dengan tidak mengoptimalkan, tetapi Anda mungkin juga kehilangan banyak penghasilan jika orang meninggalkan situs Anda frustrasi.
jpmc26

21

Ini bukan hukum alam, tetapi aturan praktis yang lahir dari pengalaman luas. Ini juga dikenal sebagai aturan 80/20, dan hanya merupakan perkiraan kasar.

Loop, Cabang dan kontrol aliran lainnya.

Setiap tempat yang memiliki if, Anda akan memiliki satu cabang yang diambil lebih sering daripada cabang lainnya. Dengan demikian lebih banyak waktu eksekusi dihabiskan untuk mengeksekusi bagian dari program, dan bukan bagian lainnya.

Setiap tempat yang memiliki perulangan yang menjalankan lebih dari sekali, Anda memiliki kode yang dieksekusi lebih dari kode di sekitarnya. Jadi lebih banyak waktu dihabiskan di sana.

Sebagai contoh, pertimbangkan:

def DoSomeWork():
    for i in range(1000000):
        DoWork(i)
    except WorkExeption:
        print("Oh No!")

Di sini print("Oh No!")hanya akan pernah berjalan maksimal satu kali, dan sering tidak pernah, sedangkan DoWork(i)akan terjadi sekitar satu juta kali.


7
Menyebutnya aturan 80/20 dapat menyebabkan kebingungan dengan prinsip Pareto , yang berlaku lebih luas dari pada pemrograman. Mungkin 90 dan 10 adalah angka praktis yang tidak memiliki makna yang tumpang tindih ini.
trichoplax

29
Ini adalah contoh dari kepala sekolah Pareto. Kedua pasangan angka sama-sama sewenang
Caleth

2
Ada dasar matematika untuk pemisahan 80/20 dalam prinsip Pareto. Mereka bukan hanya beberapa tokoh imajiner yang mewakili "banyak" dan "sedikit".
Moyli

1
@ Mooyli - Ya, "Ada dasar matematika untuk pemisahan 80/20 ...", tetapi di dunia nyata, itu tidak akan pernah (OK, secara kebetulan, jarang) persis 80/20.
Kevin Fegan

2
@trichoplax prinsip pareto berlaku sangat baik di sini. 20% dari penyebab (baris kode) menyebabkan 80% dari efek (runtime)
njzk2

16

Loop.

Saya tergoda untuk berhenti di sana! :-)

Pertimbangkan program ini

1. do_something

2. loop 10 times
3.    do_another_thing

4.    loop 5 times
5.        do_more_stuff

Jalur 1 dieksekusi sekali, sedangkan jalur 3 dieksekusi 10 kali. Melihat setiap baris secara bergantian

1 1   0.8%
2 10  8.3%
3 10  8.3%
4 50 41.3%
5 50 41.3%

Dua baris menyumbang 83% dari waktu eksekusi (dengan asumsi semua baris membutuhkan waktu yang hampir bersamaan untuk dijalankan. Jadi 40% dari program ini membutuhkan> 80%.

Dengan contoh dunia nyata yang lebih besar, ini meningkat sehingga hanya sejumlah kecil garis yang menyumbang sebagian besar waktu berjalan.

Aturan 90/10 (atau kadang-kadang menempatkan 80/20) adalah "aturan praktis" - hanya kira-kira benar.

Lihat juga Prinsip Pareto


2
Alih-alih mengatakan itu hanya kira-kira benar, saya akan mengatakan bahwa dalam banyak kasus, setidaknya 90% dari waktu akan dihabiskan untuk mengeksekusi sebagian kecil dari kode - paling banyak 10%. Jelas akan mungkin untuk memiliki program di mana semua bagian menghabiskan waktu yang sama, tetapi itu jarang terjadi.
supercat

+1 untuk referensi Prinsip Pareto. Penjelasan lebih mendalam dapat dilihat dalam video Vsauce yang fantastis ini .
Radu Murzea

5

Ketika Anda bertanya tentang waktu eksekusi saja, contoh ini mungkin bermanfaat:

int main() {
    sleep(90); // approximately 10% of the program.
    // other 90% of the program:
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    return 0;
}

Jika menjadi sedikit lebih serius, itu berarti dalam kode kehidupan nyata Anda hampir selalu memanggil fungsi berat dalam satu lingkaran (bukan sleep(90);), sedangkan sisanya 10% dari waktu Anda melakukan beberapa perhitungan single-pass.

Contoh lain adalah penanganan kesalahan di beberapa layanan HA. Setiap layanan yang sangat tersedia dirancang untuk bekerja dalam jumlah tak terbatas dalam kondisi normal. Ini beroperasi secara normal 99% dari waktu, tetapi kadang-kadang, dalam kasus kesalahan, ia menjalankan beberapa penanganan dan pemulihan kesalahan, yang mungkin bahkan lebih kompleks secara logis daripada layanan itu sendiri.


Bagus, saya berharap seseorang akan memposting contoh ekstrem ini, yang menunjukkan perbedaannya dengan jelas.
djechlin

3

Alasan 90/10 berarti sebagian kecil dari kode Anda akan diulang atau digunakan lebih dari yang lain. Ini sering digunakan untuk menyarankan bahwa Anda harus berkonsentrasi 90% dari upaya pengembangan / optimasi Anda dalam 10% dari kode Anda.

Pikirkan prosesor teks biasa, seperti Microsoft Word atau OpenOffice :

  • Dialog preferensi, tidak banyak digunakan;
  • Subrutin yang menggambar karakter digunakan sepanjang waktu.

Pepatah ini juga digunakan dalam ilmu manajemen ... Ini adalah pelajaran bagi kehidupan itu sendiri ... Artinya: memusatkan sebagian besar upaya Anda di mana memberi Anda lebih banyak hasil.


6
Jika Microsoft Word sederhana, apa contoh yang kompleks?
Peter Mortensen

@PeterMortensen itu tidak masuk akal.
The Great Duck

@PeterMortensen Emacs, jelas.
muru

2

Bayangkan sebuah program seperti ini:

print "H"
print "e"
print "l"
print "l"
print "o"
for i=0 to 1,000,000
    print "How long now?"
next
print "B"
print "y"
print "e"

Perhatikan bagaimana ada 11 baris di sini di mana 3 dari 11 adalah untuk loop, di mana berapa banyak waktu yang dihabiskan untuk sepotong kode yang agak kecil ini? Cukup banyak sementara 8 baris lainnya hanya mencetak satu karakter. Jadi, berhati-hatilah bahwa walaupun beberapa kode mungkin pendek, itu tidak memberi tahu Anda seberapa sering dieksekusi dan berapa lama waktu yang diperlukan.


0

Selain pengulangan, sebagaimana disebutkan oleh jawaban hebat lainnya, ada juga prinsip KERING yang perlu dipertimbangkan. Ditulis dengan baik, kode Berorientasi Objek memiliki banyak bagian yang dapat digunakan kembali. Bagian-bagian yang digunakan kembali, menurut definisi, digunakan setidaknya dua kali lebih sering daripada sesuatu yang hanya dijalankan sekali. Jika Anda memiliki banyak kode OO, Anda dapat berpotensi menggunakan kembali beberapa kelas dan metode berkali-kali, dan beberapa potongan kode lainnya hanya sekali.

Seperti disebutkan dalam jawaban lain, mungkin lebih baik menghabiskan upaya membuat kode yang digunakan lebih sering lebih baik daripada meningkatkan kode yang hanya digunakan satu kali.


2
Anda dapat menggunakan kembali banyak kode, tetapi semua itu dapat dieksekusi jarang (sementara masih sangat penting).
Peter Mortensen

@PeterMortensen "penting tetapi tidak sering" tidak sama dengan "digunakan kembali hampir setiap detik dan perlu secepat mungkin"
The Great Duck

@TheGreatDuck dan saya tidak berpikir itu yang dia maksud. Karena Anda dapat memiliki kode yang dieksekusi jarang tetapi Anda ingin itu terjadi secepat mungkin. Sebagai contoh, mari kita ambil pemulihan kesalahan - tergantung pada aplikasi, mungkin tidak apa-apa untuk mengambil waktu (5 menit, satu jam, mungkin lebih) untuk sistem dapat beroperasi kembali. Namun, jika, katakanlah, sistem penerbangan menemukan kesalahan, Anda benar-benar ingin itu secepat mungkin. Karena jika tidak, itu akan "turun" dan "jatuh" dalam arti yang sangat harfiah.
VLAZ

Ini sepertinya menyiratkan bahwa KERING membutuhkan OO, yang tentu saja tidak benar. Reuse sama-sama difasilitasi oleh fungsi gratis, dll.
underscore_d

@vlaz itu benar, tetapi masalahnya adalah bahwa di dalam pesawat .... SEMUA perlu berlari cepat.
The Great Duck

0

Itu bukan aturan, itu hanya beberapa pria yang mengedit Wikipedia dengan beberapa nomor ditarik keluar dari udara dan menyebutnya aturan. Bandingkan dengan Prinsip Pareto, yang lebih mapan dalam konteks lain. Saya ingin melihat penelitian apa yang telah dilakukan (jika ada) tentang keakuratan "aturan" ini.

Tetapi pada dasarnya jawaban untuk pertanyaan Anda adalah, beberapa kode dieksekusi jauh lebih sering daripada kode lainnya. Loop sering menjadi alasan untuk ini. Alasan lain adalah panggilan yang memakan waktu, misalnya sumber daya eksternal seperti layanan web atau media penyimpanan.


Itu adalah hal yang sah yang digunakan orang sebagai patokan.
The Great Duck

Jika Anda menyarankan ini digunakan secara luas sebagai aturan praktis, saya akan tertarik untuk melihat bukti untuk itu juga! Atau apakah itu hanya pendapat lain yang dikeluarkan dari udara tipis tetapi tersirat sebagai fakta?
Brad Thomas

Jika Anda benar-benar membaca artikel wikipedia, Anda akan melihat bahwa kutipan yang dirujuk oleh penanya memiliki kutipan ini: amazon.com/Every-Computer-Performance-Book-Computers/dp/... Saya secara pribadi belum pernah melihatnya menggunakannya, tetapi pos Anda dianggap kasar dan menolak menurut pendapat saya, jadi saya menanggapinya. Jelas 10% adalah angka yang dibuat seseorang. Saya dapat membuatnya berapa pun angka yang saya inginkan dengan membuat program saya tidak efisien. Namun, apakah itu istilah yang digunakan dalam rekayasa perangkat lunak jelas tidak dapat diperdebatkan mengingat berapa banyak orang di sini yang setuju dengan keberadaannya.
The Great Duck

Yah saya tidak akan pergi membeli buku hanya untuk melihat penelitian yang seharusnya mengacu ... bisakah Anda memposting kutipan dari itu yang menunjukkan bukti? Atau apakah Anda sebenarnya tidak melihatnya?
Brad Thomas

1
@BradThomas: Bukti yang menentang teori bahwa aturan 90-10 diciptakan oleh seseorang yang mengedit Wikipedia adalah dikutip secara luas, dengan angka 90 dan 10, bertahun-tahun sebelum Wikipedia ada; prinsip sebenarnya bukan 10% dari kode yang menyumbang 90% dari runtime, melainkan dalam sebagian besar program sebagian kecil dari kode - 10% atau kurang , menyumbang sebagian besar dari runtime- -90% atau lebih yang bahkan peningkatan 10% dalam kinerja bagian kecil dari kode akan mengurangi waktu eksekusi keseluruhan lebih dari peningkatan 1000x dalam segala hal lainnya.
supercat

0

Ini adalah interpretasi ulang dari "prinsip Pareto", yang menyatakan "untuk banyak peristiwa, sekitar 80% dari efek berasal dari 20% dari penyebabnya.", Juga dikenal sebagai aturan 80/20. Aturan ini sebagian besar diterapkan pada ekonomi, sehingga masuk akal bahwa itu akan dirancang ulang untuk pemrograman.

Itu hanya pola yang telah diamati selama periode waktu yang lama.

Berikut adalah video yang sangat bagus tentang pola-pola seperti ini, dan itu juga menjelaskan Prinsip Pareto.

https://www.youtube.com/watch?v=fCn8zs912OE&ab_channel=Vsauce

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.