ความหมายของกฎ 90/10 ของการเพิ่มประสิทธิภาพโปรแกรมคืออะไร

67

ตามวิกิพีเดียกฎ 90/10 ของการปรับโปรแกรมให้ดีที่สุดระบุว่า“ 90% ของเวลาดำเนินการโปรแกรมใช้ในการดำเนินการ 10% ของรหัส” (ดูย่อหน้าที่สองที่นี่ )

ฉันไม่เข้าใจสิ่งนี้จริงๆ สิ่งนี้หมายความว่าอย่างไร 90% ของเวลาในการดำเนินการสามารถใช้งานได้เพียง 10% ของรหัสเท่านั้น แล้วอีก 90% ของรหัสล่ะ? พวกเขาสามารถดำเนินการในเวลาเพียง 10% ได้อย่างไร

optimization theory program

— Rakshith Ravi
แหล่งที่มา

50

รหัสบางส่วนอาจถูกเรียกใช้งานบ่อยกว่าส่วนอื่น ๆ นั่นคือสิ่งที่ลูปมีไว้เพื่อหลังจากทั้งหมด ในทางปฏิบัติมักจะดำเนินการบางส่วนทางบ่อยกว่าส่วนอื่น ๆ

— Kilian Foth

147

รอจนกว่าคุณจะได้ยินกฎ 90/10 สำหรับระยะเวลาโครงการซอฟต์แวร์:“ 90% ของโครงการจะใช้เวลา 90% แรกของเวลาที่กำหนด; 10% สุดท้ายของโครงการจะใช้เวลา 90% ของเวลาที่กำหนด "

— Paul D. Waite

3

ความสับสนที่นี่: "เวลาที่ใช้ในการดำเนินการ" a++; for(i=0;i<100;i++){b++;} for(i=0;i<100;i++){print(xyz);}พิจารณา แน่นอนว่าครั้งแรกสำหรับวงใช้เวลามากขึ้นกว่าคำสั่งแรก แต่ที่สองสำหรับวงใช้เวลา ~ 1000x เวลามากขึ้นกว่าครั้งแรกสำหรับวงแต่ไม่ดำเนินการ มันใช้เวลามันรอสำหรับการพิมพ์ ดังนั้นจึงมีความแตกต่างระหว่างเวลาที่ใช้ในการดำเนินการและเวลาที่รหัสเป็นผู้รับผิดชอบในการ

— Mike Dunlavey

32

@ Paul_D._ รอฉันคิดว่าเป็น 90% ของโครงการใช้เวลา 90% ของเวลา 90% ของสิ่งที่เหลือใช้เวลาอีก 90% ของเวลาและอื่น ๆ ในซีรีส์ที่ไม่ได้มาบรรจบกันเพื่อสรุปว่าไม่มีโครงการเป็น เคยเสร็จสิ้นหรือยกเลิกการบั๊กอย่างสมบูรณ์ในเวลาน้อยกว่าไม่ จำกัด

— nigel222

9

สำหรับตัวอย่างที่ใช้งานได้จริงรหัสสองสามข้อที่ฉันทำงาน (แบบจำลองทางวิทยาศาสตร์) ใช้รหัสจำนวนมาก (~ 10K บรรทัด) เพื่ออ่านและตั้งค่าแบบจำลองจากนั้นวนรอบผ่านสองสามร้อยบรรทัดเพื่อทำการคำนวณจริง แต่วงสั้นนั้นคือ n ^ 4 (มิติพื้นที่สามมิติซ้ำหลายพันขั้นตอน) ดังนั้นจึงต้องใช้เวลาหลายวันในการคำนวณ ดังนั้นอัตราส่วนที่แท้จริงน่าจะมากกว่า 99% / 1% :-)

— jamesqf

184

มีหลักการพื้นฐานสองประการในการเล่นที่นี่:

โค้ดบางตัวถูกเรียกใช้งานบ่อยกว่าโค้ดอื่น ๆ ตัวอย่างเช่นอาจไม่เคยใช้รหัสการจัดการข้อผิดพลาดบางอย่าง รหัสบางอย่างจะถูกดำเนินการเฉพาะเมื่อคุณเริ่มโปรแกรมของคุณ รหัสอื่น ๆ จะถูกดำเนินการซ้ำแล้วซ้ำอีกในขณะที่โปรแกรมของคุณทำงาน
รหัสบางคนใช้เวลามากอีกต่อไปที่จะเรียกใช้จากรหัสอื่น ๆ ตัวอย่างเช่นบรรทัดเดียวที่รันเคียวรีบนฐานข้อมูลหรือดึงไฟล์จากอินเทอร์เน็ตอาจใช้เวลานานกว่าการดำเนินการทางคณิตศาสตร์นับล้าน

กฎ 90/10 นั้นไม่เป็นความจริง มันแตกต่างกันไปตามโปรแกรม (และฉันสงสัยว่ามีพื้นฐานใด ๆ กับตัวเลขเฉพาะ 90 และ 10 เลยมีคนอาจดึงพวกเขาออกมาจากอากาศบาง ๆ ) แต่ประเด็นก็คือถ้าคุณต้องการให้โปรแกรมของคุณทำงานได้เร็วขึ้นอาจมีเพียงจำนวนบรรทัดน้อยที่มีความสำคัญในการทำให้เกิดขึ้น การระบุส่วนที่ช้าของซอฟต์แวร์ของคุณมักเป็นส่วนที่ใหญ่ที่สุดของการปรับให้เหมาะสม

นี่เป็นข้อมูลเชิงลึกที่สำคัญและหมายความว่าการตัดสินใจที่ดูเหมือนจะเป็นเรื่องง่ายสำหรับนักพัฒนาใหม่มักจะถูกต้อง ตัวอย่างเช่น:

มีโค้ดจำนวนมากที่ไม่คุ้มค่ากับเวลาของคุณที่จะทำให้ "ดีขึ้น"แม้ว่ามันจะทำสิ่งต่าง ๆ ในวิธีที่โง่และเรียบง่าย คุณช่วยเขียนอัลกอริธึมการค้นหาที่มีประสิทธิภาพมากขึ้นสำหรับ XYZ แอปพลิเคชันได้ไหม ใช่ แต่จริงๆแล้วการเปรียบเทียบค่าทุกอย่างง่าย ๆ ใช้เวลาเล็กน้อยแม้ว่าจะมีค่าหลายพันก็ตาม ดังนั้นมันจึงไม่คุ้มค่า มันอาจเป็นเรื่องยากสำหรับนักพัฒนาใหม่ที่จะหลีกเลี่ยงการเพิ่มประสิทธิภาพที่ไม่จำเป็นเพราะในหลักสูตรปริญญาของพวกเขาใช้เวลามากในการเขียนอัลกอริทึม "ถูกต้อง" (หมายถึงมีประสิทธิภาพมากที่สุด) แต่ในโลกแห่งความเป็นจริงอัลกอริธึมที่ถูกต้องคือสิ่งที่ทำงานและทำงานได้เร็วพอ
การเปลี่ยนแปลงที่ทำให้โค้ดของคุณใช้เวลานานขึ้นและมีความซับซ้อนมากขึ้นอาจเป็นผลงานที่มีประสิทธิภาพ ตัวอย่างเช่นในแอปพลิเคชั่น FOO อาจเป็นการเพิ่มตรรกะใหม่หลายร้อยบรรทัดเพื่อหลีกเลี่ยงการเรียกฐานข้อมูลเดียว

6

โดยเฉพาะอย่างยิ่งโน้ตด้วยสิ่งต่าง ๆ เช่นฟังก์ชั่นการเรียงลำดับมันเร็วกว่ามาก (ในเวลา dev) และง่ายกว่าที่จะสร้าง algo แบบง่าย ๆ ทำสิ่งที่ถูกต้องในทุกกรณี (เหตุผลเดียวที่จะเขียนอัลโกแบบเรียงนอกอะคาเดมีคือถ้าคุณกำลังสร้างห้องสมุดหรือทำงานบนแพลตฟอร์มโดยไม่มีใครเลย…)

— StarWeaver

5

ฉันคิดว่าคุณจำเป็นต้องเพิ่มการเชื่อมโยงไปshouldioptimize.com :)

— อีวาน Kolmychek

13

ฉันคิดว่า 90/10 มาจาก 80/20 Pareto Principle ที่รู้จักกันดีen.wikipedia.org/wiki/Pareto_principle

— fernando.reyes

2

@StarWeaver ซึ่งเป็นเหตุผลว่าทำไมภาษาที่ทำให้การเขียนแปลก ๆ มีประสิทธิภาพเป็นเรื่องง่ายหรือง่ายกว่าการเรียงลำดับฟองมีความสำคัญเช่น C ++ อัลกอริทึมและโค้ด "prepackaged" ดังกล่าวสามารถปรับให้เหมาะสมอย่างมากโดยไม่ทำให้เกิดความซับซ้อน ณ จุดใช้งาน

— Yakk

6

@IvanKolmychek ไซต์นั้นทำให้เข้าใจผิด แน่นอนว่าการวิเคราะห์ต้นทุนนั้นเป็นปัจจัยหนึ่งที่ต้องพิจารณา แต่มีปัจจัยอื่น ๆ เช่นประสบการณ์ของผู้ใช้ คุณอาจประหยัดเงินเป็นจำนวนมากโดยไม่เพิ่มประสิทธิภาพ แต่คุณอาจพลาดโอกาสในการได้รับรายได้มากมายหากผู้คนออกจากเว็บไซต์ของคุณด้วยความผิดหวัง

— jpmc26

21

นี่ไม่ใช่กฎของธรรมชาติ แต่กฎของหัวแม่มือเกิดจากประสบการณ์มากมาย มันเป็นที่รู้จักกันว่ากฎ 80/20 และเป็นเพียงการประมาณคร่าวๆ

ลูปสาขาและการควบคุมการไหลอื่น ๆ

แต่ละสถานที่ที่มีถ้าคุณจะมีหนึ่งสาขาที่ถูกนำบ่อยกว่าสาขาอื่น ดังนั้นเวลาดำเนินการมากขึ้นจึงใช้เวลาในการดำเนินการส่วนหนึ่งของโปรแกรมไม่ใช่ส่วนอื่น

แต่ละสถานที่ที่มีการวนซ้ำที่รันมากกว่าหนึ่งครั้งคุณมีรหัสที่ถูกเรียกใช้มากกว่ารหัสโดยรอบ ดังนั้นจึงใช้เวลามากขึ้น

เป็นตัวอย่างให้พิจารณา:

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

ที่นี่print("Oh No!")จะทำงานเพียงครั้งเดียวสูงสุดและมักจะไม่เคยในขณะที่DoWork(i)จะเกิดขึ้นประมาณล้านครั้ง

— Caleth
แหล่งที่มา

7

การเรียกว่ากฎ 80/20 อาจทำให้เกิดความสับสนกับหลักการของ Paretoซึ่งใช้ในวงกว้างมากกว่าการตั้งโปรแกรม บางที 90 และ 10 เป็นเพียงตัวเลขที่สะดวกที่ไม่มีความหมายทับซ้อนกัน

— trichoplax

29

มันเป็นตัวอย่างของอาจารย์ใหญ่ของพาเรโต ตัวเลขทั้งคู่เป็นกฎเกณฑ์ที่เท่าเทียมกัน

— Caleth

2

มีพื้นฐานทางคณิตศาสตร์สำหรับการแบ่ง 80/20 ในหลักการ Pareto พวกเขาไม่ได้เป็นเพียงบุคคลในจินตนาการที่จะแสดง "มาก" และ "เล็กน้อย"

— Moyli

1

@Moyli - ใช่ "มีพื้นฐานทางคณิตศาสตร์สำหรับการแบ่ง 80/20 ... " แต่ในโลกแห่งความเป็นจริงมันจะไม่มีทาง (ตกลงโดยบังเอิญไม่ค่อยมี) 80/20

— Kevin Fegan

2

@ ตรีโกณมิติหลักการพาเรโต้ใช้ดีมากที่นี่ 20% ของสาเหตุ (บรรทัดโค้ด) ทำให้ 80% ของเอฟเฟกต์ (รันไทม์)

— njzk2

16

ลูป

ฉันอยากจะหยุดตรงนั้น! :-)

พิจารณาโปรแกรมนี้

1. do_something

2. loop 10 times
3.    do_another_thing

4.    loop 5 times
5.        do_more_stuff

บรรทัดที่ 1 จะถูกดำเนินการครั้งเดียวในขณะที่สาย 3 ถูกดำเนินการ 10 ครั้ง มองไปที่แต่ละบรรทัดในทางกลับกัน

สองบรรทัดคิดเป็น 83% ของเวลาดำเนินการ (สมมติว่าทุกบรรทัดใช้เวลาในการรันเท่ากันดังนั้นโปรแกรม 40% ใช้เวลา> 80%

ด้วยตัวอย่างในโลกแห่งความเป็นจริงที่มีขนาดใหญ่ขึ้นสิ่งนี้จะเพิ่มขึ้นดังนั้นมีจำนวนบรรทัดน้อยที่ใช้เวลามาก

กฎ 90/10 (หรือบางครั้งใส่ 80/20) เป็น "กฎง่ายๆ" - จริงโดยประมาณเท่านั้น

ดูเพิ่มเติมที่หลักการพาเรโต้

— Nick Keighley
แหล่งที่มา

2

แทนที่จะบอกว่าเป็นเรื่องจริงโดยประมาณฉันจะบอกว่าในหลาย ๆ กรณีอย่างน้อย 90% ของเวลาจะถูกใช้ในการประมวลผลโค้ดเพียงเล็กน้อย - มากที่สุด 10% เห็นได้ชัดว่ามันเป็นไปได้ที่จะมีโปรแกรมที่ทุกส่วนใช้เวลาประมาณเท่ากันในการดำเนินการ

— supercat

+1 สำหรับการอ้างอิงหลักการ Pareto คำอธิบายในเชิงลึกเพิ่มเติมสามารถดูได้ในวิดีโอ Vsauceอันน่าอัศจรรย์นี้

— Radu Murzea

5

เมื่อคุณถามเกี่ยวกับเวลาดำเนินการเท่านั้นตัวอย่างนี้อาจมีประโยชน์:

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

ถ้าหากจะจริงจังมากขึ้นเล็กน้อยก็หมายความว่าในรหัสชีวิตจริงคุณมักจะเรียกฟังก์ชั่นหนัก ๆ ในลูป (แทนsleep(90);) ในขณะที่เวลาที่เหลือ 10% ของเวลาที่คุณทำการคำนวณแบบผ่านครั้งเดียว

อีกตัวอย่างหนึ่งคือการจัดการข้อผิดพลาดในบริการ HA บางอย่าง บริการที่มีความพร้อมใช้งานสูงถูกออกแบบมาให้ทำงานได้ไม่ จำกัดจำนวนภายใต้เงื่อนไขปกติ มันทำงานได้ตามปกติ 99% ของเวลา แต่บางครั้งในกรณีที่เกิดข้อผิดพลาดมันจะจัดการข้อผิดพลาดและการกู้คืนซึ่งอาจมีความซับซ้อนทางตรรกะมากกว่าตัวบริการ

— Sergey
แหล่งที่มา

ดีฉันหวังว่าจะมีคนโพสต์ตัวอย่างที่ยอดเยี่ยมนี้

— djechlin

3

การให้เหตุผล 90/10 หมายถึงส่วนเล็ก ๆ ของรหัสของคุณจะถูกทำซ้ำหรือใช้มากกว่าคนอื่น ๆ สิ่งนี้มักจะใช้เพื่อแนะนำว่าคุณควรมีสมาธิ 90% ของความพยายามในการพัฒนา / การเพิ่มประสิทธิภาพใน 10% ของรหัสนี้

คิดว่าโปรแกรมประมวลผลข้อความปกติเช่นMicrosoft WordหรือOpenOffice :

กล่องโต้ตอบการตั้งค่าไม่ได้ใช้มากนัก
รูทีนย่อยที่ใช้อักขระเสมอตลอดเวลา

คำพูดนี้ยังใช้ในวิทยาศาสตร์การจัดการ ... นี่คือบทเรียนสู่ชีวิตของตัวเอง ... ความหมาย: มุ่งความพยายามส่วนใหญ่ของคุณที่จะให้ผลลัพธ์มากขึ้น

— ลูคัส
แหล่งที่มา

6

ถ้า Microsoft Word นั้นง่ายตัวอย่างของคอมเพล็กซ์คืออะไร

— Peter Mortensen

@PeterMortensen ที่ไม่สมเหตุสมผล

— The Great Duck

@PeterMortensen Emacs ชัด

— muru

2

ลองนึกภาพโปรแกรมเช่นนี้:

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"

โปรดสังเกตว่ามี 11 บรรทัดที่นี่โดยที่ 3 จาก 11 เป็น for for loop ซึ่งเวลาที่ใช้ไปกับโค้ดขนาดเล็กนี้เป็นเท่าใด ค่อนข้างน้อยในขณะที่อีก 8 บรรทัดกำลังพิมพ์อักขระเพียงตัวเดียว ดังนั้นโปรดระวังว่าในขณะที่บางรหัสอาจสั้น แต่ก็ไม่ได้บอกคุณว่ามันถูกเรียกใช้งานบ่อยแค่ไหนและใช้เวลานานเท่าใด

— JB King
แหล่งที่มา

0

นอกเหนือจากการวนซ้ำตามคำตอบที่ยอดเยี่ยมอื่น ๆ แล้วยังมีหลักการที่ต้องพิจารณาอีกด้วย เขียนได้ดีรหัส Object Oriented มีชิ้นส่วนที่นำมาใช้ซ้ำได้จำนวนมาก ชิ้นส่วนเหล่านั้นที่นำกลับมาใช้ใหม่โดยการใช้อย่างน้อยสองครั้งบ่อยเท่าสิ่งที่จะถูกดำเนินการเพียงครั้งเดียว หากคุณมีรหัส OO จำนวนมากคุณอาจนำคลาสและวิธีการมาใช้ซ้ำหลายครั้งหลายครั้งและอีกสองสามชิ้นของรหัสเพียงครั้งเดียว

ดังที่กล่าวไว้ในคำตอบอื่น ๆ อาจเป็นการดีกว่าที่จะใช้ความพยายามในการสร้างรหัสที่ใช้บ่อยกว่าการปรับปรุงรหัสที่ใช้เพียงครั้งเดียวเท่านั้น

— Marshall Tigerus
แหล่งที่มา

2

คุณสามารถนำโค้ดจำนวนมากมาใช้ใหม่ได้ แต่ทั้งหมดนั้นสามารถเรียกใช้งานได้ไม่บ่อยนัก (ในขณะที่ยังคงสำคัญอยู่)

— Peter Mortensen

@PeterMortensen "สำคัญ แต่ไม่บ่อย" ไม่เหมือนกับ "นำกลับมาใช้ใหม่เกือบทุกวินาทีและต้องการให้เร็วที่สุด"

— The Great Duck

@TheGreatDuck และฉันไม่คิดว่านั่นคือสิ่งที่เขาหมายถึง เพราะคุณสามารถมีรหัสที่รันไม่บ่อยนัก แต่คุณต้องการให้มันเกิดขึ้นเร็วที่สุดเท่าที่จะเป็นไปได้ ตัวอย่างเช่นลองกู้คืนข้อผิดพลาด - ขึ้นอยู่กับแอปพลิเคชันอาจใช้เวลาสักครู่ (5 นาทีต่อชั่วโมงหรืออาจมากกว่า) เพื่อให้ระบบกลับมาทำงานได้อีกครั้ง อย่างไรก็ตามหากระบบการบินพบข้อผิดพลาดคุณต้องการให้มันเร็วที่สุดเท่าที่จะทำได้ เพราะถ้ามันไม่เป็นเช่นนั้น "ลงไป" และ "ผิดพลาด" ในความหมายที่แท้จริงมาก

— VLAZ

สิ่งนี้ดูเหมือนจะบอกเป็นนัยว่า DRY ต้องการ OO ซึ่งแน่นอนว่าไม่เป็นความจริง การนำมาใช้ซ้ำได้รับการอำนวยความสะดวกอย่างเท่าเทียมกันโดยฟังก์ชั่นฟรี ฯลฯ

— underscore_d

@ vlaz ที่เป็นจริง แต่สิ่งที่อยู่ในเครื่องบิน .... ทุกอย่างต้องทำงานอย่างรวดเร็ว

— The Great Duck

0

นั่นไม่ใช่กฎนั่นเป็นเพียงเพื่อนบางคนที่แก้ไขวิกิพีเดียด้วยตัวเลขสองสามตัวดึงออกมาจากอากาศที่บางเบาและเรียกมันว่ากฎ เปรียบเทียบกับหลักการ Pareto ซึ่งเป็นที่ยอมรับอย่างมั่นคงในบริบทอื่น ๆ ฉันต้องการดูว่ามีการวิจัยใดที่ทำ (ถ้ามี) เกี่ยวกับความถูกต้องของ "กฎ" นี้

แต่โดยทั่วไปคำตอบสำหรับคำถามของคุณคือบางรหัสถูกเรียกใช้บ่อยกว่าโค้ดอื่น ลูปมักเป็นสาเหตุของเรื่องนี้ เหตุผลอื่น ๆ คือการโทรที่ใช้เวลานานเช่นไปยังแหล่งข้อมูลภายนอกเช่นบริการเว็บหรือสื่อเก็บข้อมูล

— แบรดโธมัส
แหล่งที่มา

มันเป็นสิ่งที่ถูกกฎหมายที่ผู้คนใช้เป็นกฎง่ายๆ

— The Great Duck

หากคุณแนะนำว่านี่เป็นการใช้งานทั่วไปอย่างกว้างขวางฉันก็สนใจที่จะเห็นหลักฐานสำหรับสิ่งนั้นด้วย! หรือว่าเป็นเพียงความคิดเห็นอื่นที่ดึงออกมาจากอากาศบาง แต่โดยนัยว่าเป็นความจริง?

— แบรดโทมัส

หากคุณอ่านบทความวิกิพีเดียจริง ๆ แล้วคุณจะเห็นว่าข้อความที่อ้างถึงโดยผู้ถามมีการอ้างอิงนี้: amazon.com/Every-Computer-Performance-Book-Computers/dp/ …ฉันไม่เคยเห็นมันมาใช้เลย แต่คุณโพสต์เจอว่าหยาบคายและไม่ยอมรับความคิดเห็นของฉันดังนั้นฉันจึงตอบกลับ เห็นได้ชัดว่า 10% เป็นตัวเลขที่มีคนสร้างขึ้น ฉันสามารถทำให้เป็นตัวเลขใดก็ได้ตามที่ฉันต้องการโดยทำให้โปรแกรมของฉันไม่มีประสิทธิภาพ อย่างไรก็ตามไม่ว่าจะเป็นคำที่ใช้ในวิศวกรรมซอฟต์แวร์หรือไม่ก็เป็นที่ถกเถียงกันอยู่ว่ามีกี่คนที่เห็นด้วยกับการดำรงอยู่ของมัน

— The Great Duck

ฉันไม่ได้กำลังจะไปซื้อหนังสือเพื่อดูงานวิจัยที่อ้างถึง ... คุณช่วยโพสต์ข้อความที่แสดงหลักฐานได้หรือไม่? หรือในความเป็นจริงคุณไม่เคยเห็นใคร?

— แบรดโทมัส

1

@BradThomas: หลักฐานที่ต่อต้านทฤษฎีที่ว่า 90-10 กฎถูกคิดค้นโดยคนที่แก้ไข Wikipedia ก็คือมันถูกอ้างถึงอย่างกว้างขวางโดยมีตัวเลข 90 และ 10 หลายปีก่อนที่ Wikipedia จะมีอยู่ หลักการที่แท้จริงไม่ใช่ว่า 10% ของรหัสบัญชีคิดเป็น 90% ของรันไทม์ แต่ในโปรแกรมส่วนใหญ่มีโค้ดเพียงเล็กน้อย - 10% หรือน้อยกว่านั้นบัญชีสำหรับส่วนใหญ่ของ runtime - -90% หรือมากกว่านั้นแม้แต่การปรับปรุง 10% ในประสิทธิภาพของส่วนเล็ก ๆ ของรหัสนั้นจะช่วยลดเวลาในการดำเนินการโดยรวมมากกว่าการปรับปรุง 1000 เท่าในทุกสิ่งอื่น ๆ

— supercat

0

มันเป็นการตีความใหม่ของ "หลักการ Pareto" ซึ่งระบุว่า "สำหรับเหตุการณ์ต่าง ๆ ประมาณ 80% ของเอฟเฟกต์มาจาก 20% ของสาเหตุ" หรือที่เรียกว่ากฎ 80/20 กฎนี้ใช้กับเศรษฐศาสตร์เป็นส่วนใหญ่ดังนั้นจึงเหมาะสมที่จะนำมาใช้สำหรับการเขียนโปรแกรม

มันเป็นเพียงลวดลายที่ถูกสังเกตมาเป็นเวลานาน

นี่คือวิดีโอที่ยอดเยี่ยมมากเกี่ยวกับรูปแบบเช่นนี้และมันยังอธิบายหลักการของพาเรโต

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

— imnota4
แหล่งที่มา