कार्यक्रम अनुकूलन के 90/10 नियम का क्या अर्थ है?

Question

विकिपीडिया के अनुसार, प्रोग्राम ऑप्टिमाइज़ेशन के 90/10 नियम में कहा गया है कि "प्रोग्राम के निष्पादन का 90% समय कोड के 10% को निष्पादित करने में खर्च होता है" (दूसरा पैराग्राफ यहां देखें )।

मैं वास्तव में यह नहीं समझता। इसका वास्तव में क्या मतलब है? निष्पादन समय का 90% केवल 10% कोड को निष्पादित करने में कैसे खर्च किया जा सकता है? फिर अन्य 90% कोड के बारे में क्या? केवल 10% समय में उन्हें कैसे निष्पादित किया जा सकता है?

Comments

कोड के कुछ हिस्सों को अन्य भागों की तुलना में अधिक बार निष्पादित किया जा सकता है। यही लूप सभी के लिए हैं। अभ्यास में, लगभग हमेशा कुछ भागों क्रियान्वित कर रहे हैं जिस तरह से दूसरों की तुलना में अधिक बार।

— किलन फ़ॉथ

सॉफ़्टवेयर प्रोजेक्ट अवधि के लिए 90/10 नियम सुनने तक प्रतीक्षा करें: “प्रोजेक्ट का 90% आवंटित समय का पहला 90% लेगा; परियोजना का अंतिम 10% आवंटित समय के अन्य 90% को ले जाएगा। ”

— पॉल डी। वेट

यहाँ भ्रम: "समय को क्रियान्वित करने में व्यतीत होता है"। विचार करें a++; for(i=0;i<100;i++){b++;} for(i=0;i<100;i++){print(xyz);}। निश्चित रूप से पहला फॉर-लूप पहले स्टेटमेंट की तुलना में बहुत अधिक खर्च करता है, लेकिन दूसरा फॉर-लूप पहले फॉर-लूप की तुलना में ~ 1000x अधिक समय खर्च करता है, लेकिन निष्पादित नहीं होता है । यह इसे प्रिंट के इंतजार में खर्च करता है । इसलिए निष्पादन पर खर्च किए गए समय और कोड के लिए जिम्मेदार समय के बीच अंतर है ।

— माइक डनलैवी

@ पॉल_ डी__ मुझे लगता है कि यह था कि 90% परियोजना में 90% समय लगता है, जो बचा है उसका 90% समय एक और 90% लेता है, और इसलिए एक गैर-अभिसरण श्रृंखला नीचे इस निष्कर्ष पर पहुंचती है कि कोई परियोजना नहीं है अनंत समय से भी कम समय में समाप्त या पूरी तरह से समाप्त हो गया।

— nigel222 15

व्यावहारिक उदाहरणों के लिए, मैंने जिन कोड (वैज्ञानिक मॉडल) पर काम किया था उनमें से एक कोड ने मॉडल को पढ़ने और स्थापित करने के लिए बड़ी मात्रा में कोड (~ 10K लाइनों) का उपयोग किया, फिर वास्तविक गणना करने के लिए कुछ सौ लाइनों के माध्यम से एक लूप किया। लेकिन वह छोटा लूप n ^ 4 था (तीन अंतरिक्ष समय कई हजारों चरणों के माध्यम से पुनरावृत्त हुआ), इसलिए गणना करने में कई दिन लग गए। तो वास्तविक अनुपात संभवतः 99% / 1% :-)

— jamesqf

Answer 1

यहाँ खेलने के दो मूल सिद्धांत हैं:

• कुछ कोड को अन्य कोड की तुलना में बहुत अधिक बार निष्पादित किया जाता है। उदाहरण के लिए, कुछ त्रुटि हैंडलिंग कोड का उपयोग कभी नहीं किया जा सकता है। कुछ कोड केवल तभी निष्पादित किए जाएंगे जब आप अपना कार्यक्रम शुरू करेंगे। आपके प्रोग्राम के चलने के दौरान अन्य कोड को बार-बार निष्पादित किया जाएगा।
• कुछ कोड को अन्य कोड की तुलना में चलने में अधिक समय लगता है । उदाहरण के लिए, एक एकल लाइन जो एक डेटाबेस पर एक क्वेरी चलाता है, या इंटरनेट से एक फ़ाइल खींचती है, शायद लाखों गणितीय कार्यों से अधिक समय लगेगा।

90/10 नियम अक्षरशः सत्य नहीं है। यह कार्यक्रम से भिन्न होता है (और मुझे संदेह है कि विशिष्ट संख्या 90 और 10 के आधार पर कोई भी है; किसी ने शायद उन्हें पतली हवा से निकाला है)। लेकिन मुद्दा यह है, अगर आपको अपने कार्यक्रम को तेज गति से चलाने की आवश्यकता है, तो शायद ऐसा करने के लिए केवल कुछ ही पंक्तियाँ महत्वपूर्ण हैं। आपके सॉफ़्टवेयर के धीमे भागों की पहचान अक्सर अनुकूलन का सबसे बड़ा हिस्सा है।

यह एक महत्वपूर्ण अंतर्दृष्टि है, और इसका मतलब है कि एक नए डेवलपर के लिए प्रतिसाद देने वाले निर्णय अक्सर सही हो सकते हैं। उदाहरण के लिए:

• बहुत सारे कोड हैं जो "बेहतर" बनाने के लिए आपके समय के लायक नहीं है , भले ही वह चीजों को गूंगा, सरल तरीके से कर रहा हो। आप अनुप्रयोग XYZ के लिए एक अधिक कुशल खोज एल्गोरिदम लिख सकते हैं? हां, लेकिन वास्तव में हर मूल्य की एक साधारण तुलना में एक तुच्छ मात्रा में समय लगता है, भले ही हजारों मूल्य हों। तो यह सिर्फ इसके लायक नहीं है। नए डेवलपर्स के लिए अनावश्यक अनुकूलन से बचना कठिन हो सकता है, क्योंकि उनके डिग्री प्रोग्राम में "सही" (सबसे कुशल) एल्गोरिथ्म लिखने में बहुत समय खर्च किया गया था। लेकिन वास्तविक दुनिया में, सही एल्गोरिदम कोई भी है जो काम करता है और तेजी से चलता है।
• आपके कोड को अधिक लंबे और अधिक जटिल बनाने वाले परिवर्तन अभी भी एक प्रदर्शन जीत हो सकते हैं। उदाहरण के लिए, एप्लिकेशन FOO में यह केवल एक डेटाबेस कॉल से बचने के लिए नए तर्क की सैकड़ों लाइनें जोड़ने के लायक हो सकता है।

Comments

विशेष रूप से, छँटाई कार्यों जैसी चीजों के साथ, यह बहुत तेज़ (देव समय में) है और एक सरल गूंगा बनाने के लिए सभी मामलों में सही काम करना आसान है, जिससे एक सुरुचिपूर्ण अहंकार पूरी तरह से कार्यात्मक और बग रहित हो। (एकेडमिया के बाहर एक तरह का एल्गो लिखने का एकमात्र कारण यदि आप एक पुस्तकालय का निर्माण कर रहे हैं या एक के बिना एक मंच पर काम कर रहे हैं)

— StarWeaver

मुझे लगता है कि आपको लिंक जोड़ने की जरूरत है shouldioptimize.com :)

— इवान कोलमिचेक

मुझे लगता है कि 90/10 प्रसिद्ध 80/20 परेतो सिद्धांत से आता है en.wikipedia.org/wiki/Pareto_principle

— fernando.reyes

@StarWeaver यही वजह है कि गंदे बबल-सॉर्ट की तुलना में आसान या आसान लिखने वाली भाषाएँ C ++ जैसी महत्वपूर्ण हैं। इस तरह के "प्रीपैक्ड" एल्गोरिदम और कोड को उपयोग के बिंदु पर जटिलता पैदा किए बिना वास्तव में भारी रूप से अनुकूलित किया जा सकता है।

— याकूब

@IvanKolmychek यह साइट भ्रामक है। निश्चित रूप से, उस तरह का लागत विश्लेषण विचार करने के लिए एक कारक है, लेकिन उपयोगकर्ता अनुभव जैसे अन्य कारक हैं। आप अनुकूलन न करके बहुत सारा पैसा बचा सकते हैं, लेकिन अगर आपकी साइट को लोग निराश छोड़ देते हैं, तो आप बहुत अधिक आय से चूक सकते हैं।

— jpmc26

Answer 2

यह प्रकृति का नियम नहीं है, लेकिन व्यापक अनुभव द्वारा पैदा होने वाले अंगूठे का एक नियम है। यह 80/20 नियम के रूप में भी जाना जाता है, और केवल कभी-कभी एक मोटा अनुमान है।

छोरों, शाखाओं और अन्य प्रवाह नियंत्रण।

प्रत्येक स्थान पर यदि एक है, तो आपके पास एक शाखा होगी जिसे दूसरी शाखा की तुलना में अधिक बार लिया जाता है। इस प्रकार, निष्पादन का अधिक समय कार्यक्रम के उस भाग को निष्पादित करने में व्यतीत होता है, न कि दूसरे भाग पर।

प्रत्येक स्थान पर एक लूप है जो एक से अधिक बार चलता है, आपके पास कोड है जो आसपास के कोड से अधिक निष्पादित होता है। इस प्रकार अधिक समय वहाँ व्यतीत होता है।

एक उदाहरण के रूप में, विचार करें:

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

यहाँ print("Oh No!")वसीयत केवल एक बार ही अधिकतम चलेगी, और अक्सर कभी नहीं, जबकि DoWork(i)वसीयत एक लाख बार होगी।

Comments

इसे 80/20 नियम कहे जाने से पेरेटो सिद्धांत के साथ भ्रम पैदा हो सकता है , जो सिर्फ प्रोग्रामिंग की तुलना में अधिक व्यापक रूप से लागू होता है। हो सकता है कि 90 और 10 ऐसे सुविधाजनक नंबर हों, जिनके अर्थ में यह ओवरलैप न हो।

— ट्राइकोप्लाक्स

यह पेरेटो प्रिंसिपल का एक उदाहरण है। संख्या के दोनों जोड़े समान रूप से मनमानी हैं

— कैलथ

पेरेटो सिद्धांत में 80/20 के विभाजन का गणितीय आधार है। वे "बहुत" और "थोड़ा" का प्रतिनिधित्व करने के लिए कुछ काल्पनिक आंकड़े नहीं हैं।

— मोयली

@ मैयली - हां, "80/20 के विभाजन का एक गणितीय आधार है ...", लेकिन वास्तविक दुनिया में, यह कभी नहीं होगा (ठीक है, संयोग से, शायद ही कभी) बिल्कुल 80/20 हो।

— केविन फेगन

@trichoplax परेटो सिद्धांत यहाँ बहुत अच्छी तरह से लागू होता है। 20% कारण (कोड लाइन्स) 80% प्रभाव (रनटाइम) का कारण बनता है

— njzk2

Answer 3

लूप्स।

मुझे वहाँ रुकने का लालच है! :-)

इस कार्यक्रम पर विचार करें

1. do_something

2. loop 10 times
3.    do_another_thing

4.    loop 5 times
5.        do_more_stuff

लाइन 1 को एक बार निष्पादित किया जाता है जबकि लाइन 3 को 10 बार निष्पादित किया जाता है। प्रत्येक पंक्ति को बारी-बारी से देखते रहे

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

निष्पादन समय के दो चरणों में 83% है (सभी पंक्तियों को चलाने के लिए समान समय लगता है। इसलिए कार्यक्रम का 40% हिस्सा 80% लेता है।

अधिक वास्तविक दुनिया के उदाहरणों के साथ, यह बहुत ही कम समय के लिए लाइनों की एक छोटी राशि का कारण बनता है।

90/10 नियम (या जैसा कि कभी-कभी इसे 80/20 डाल दिया जाता है) एक "अंगूठे का नियम" है - केवल लगभग सच है।

परेटो सिद्धांत भी देखें

Comments

यह कहने के बजाय कि यह केवल लगभग सत्य है, मैं कहूंगा कि कई मामलों में, कम से कम 90% समय कोड के एक छोटे से हिस्से को निष्पादित करने में खर्च किया जाएगा - अधिकतम 10%। जाहिर है कि उन कार्यक्रमों को करना संभव होगा जहां सभी भागों को क्रियान्वित करने में समान समय खर्च होता है, लेकिन यह दुर्लभ है।

— सुपरकैट

पेरेटो सिद्धांत को संदर्भित करने के लिए +1। इस शानदार Vuceuce वीडियो में अधिक गहराई से व्याख्या देखी जा सकती है ।

— रादु मर्ज़िया

Answer 4

जैसा कि आपने केवल निष्पादन समय के बारे में पूछा है, यह उदाहरण सहायक हो सकता है:

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% समय आप कुछ एकल पास अभिकलन करते हैं।

एक अन्य उदाहरण कुछ हा सेवा में त्रुटि हैंडलिंग है। किसी भी अत्यधिक उपलब्ध सेवा को सामान्य परिस्थितियों में अनंत समय तक काम करने के लिए डिज़ाइन किया गया है । यह सामान्य रूप से 99% समय संचालित करता है, लेकिन कभी-कभी, एक त्रुटि के मामले में, यह कुछ त्रुटि से निपटने और पुनर्प्राप्ति चलाता है, जो स्वयं सेवा की तुलना में अधिक तार्किक रूप से जटिल हो सकता है।

Comments

अच्छा, मैं उम्मीद कर रहा था कि कोई व्यक्ति इस चरम उदाहरण को पोस्ट करेगा, जो स्पष्ट रूप से अंतर दिखाता है।

— djechlin

Answer 5

90/10 तर्क का मतलब है कि आप का एक छोटा सा कोड दूसरों की तुलना में दोहराया या उपयोग किया जाएगा। इसका उपयोग अक्सर यह सुझाव देने के लिए किया जाता है कि आपको अपने विकास के 90% / अनुकूलन प्रयास को अपने 10% कोड में केंद्रित करना चाहिए।

Microsoft Word या OpenOffice जैसे सामान्य टेक्स्ट प्रोसेसर के बारे में सोचें :

• वरीयताओं का संवाद, अधिक उपयोग नहीं किया जाता है;
• पात्रों को आकर्षित करने वाले सबरूटीन्स का उपयोग हर समय किया जाता है।

यह कहावत प्रबंधन विज्ञान में भी प्रयोग की जाती है ... यह जीवन का एक सबक है ... अर्थ: अपने अधिकांश प्रयासों को केंद्रित करें जहां आपको अधिक परिणाम मिलता है।

Comments

यदि Microsoft Word सरल है, तो एक जटिल का उदाहरण क्या है?

— पीटर मोर्टेंसन

@PeterMortensen जिसका कोई अर्थ नहीं है।

— द ग्रेट डक

@PeterMortensen Emacs, जाहिर है।

— मुरु

Answer 6

इस तरह एक कार्यक्रम की कल्पना करो:

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 लाइनें कैसे हैं जहां 11 में से 3 लूप के लिए हैं, जहां कोड के इस छोटे से टुकड़े पर कितना समय खर्च होता है? थोड़ा सा जबकि अन्य 8 लाइनें केवल एक ही चरित्र को मुद्रित कर रही हैं। इस प्रकार, सावधान रहें कि कुछ कोड कम हो सकते हैं, लेकिन यह आपको नहीं बताता है कि इसे कितनी बार निष्पादित किया गया है और इसमें कितना समय लगेगा।

Answer 7

लूपिंग के अलावा, जैसा कि अन्य महान उत्तरों द्वारा उल्लेख किया गया है, विचार करने के लिए DRY सिद्धांत भी हैं। अच्छी तरह से लिखा गया है, ऑब्जेक्ट ओरिएंटेड कोड में बहुत सारे पुन: उपयोग योग्य भाग हैं। जिन भागों का पुन: उपयोग किया जाता है, परिभाषा के अनुसार, कम से कम दो बार उपयोग किया जाता है जैसे कि कुछ ऐसा जो केवल एक बार निष्पादित होता है। यदि आपके पास बहुत अधिक OO कोड है, तो आप संभवतः कई बार कुछ वर्गों और विधियों का पुन: उपयोग कर सकते हैं, और कोड के कुछ अन्य टुकड़े केवल एक बार।

जैसा कि अन्य उत्तरों में उल्लेख किया गया है, संभवतः कोड बनाने में खर्च करना बेहतर है जो कि कोड को बेहतर बनाने की तुलना में अधिक बार उपयोग किया जाता है जो केवल एक बार उपयोग किया जाता है।

Comments

आप बहुत सारे कोड का पुन: उपयोग कर सकते हैं, लेकिन यह सब अनैतिक रूप से निष्पादित किया जा सकता है (जबकि अभी भी महत्वपूर्ण है)।

— पीटर मोर्टेनसेन

@PeterMortensen "महत्वपूर्ण लेकिन अक्सर नहीं" "लगभग हर दूसरे का पुन: उपयोग नहीं किया जाता है और जितनी जल्दी हो सके इसकी आवश्यकता होती है"

— ग्रेट डक

@ TheGreatDuck और मुझे नहीं लगता कि उसका यही मतलब है। तुम्हारी वजह सकते हैं कोड है कि बार बार निष्पादित किया जाता है, लेकिन आप इसे यथासंभव शीघ्रता से हो करना चाहते हैं। एक उदाहरण के लिए, आइए त्रुटि सुधार करें - आवेदन के आधार पर, सिस्टम को फिर से चालू करने के लिए कुछ समय (5 मिनट, एक घंटा, शायद अधिक) लेना ठीक हो सकता है। हालांकि, अगर, कहते हैं, एक उड़ान प्रणाली एक त्रुटि का सामना करती है, तो आप वास्तव में इसे जितनी जल्दी हो सके उतना जल्दी चाहते हैं। क्योंकि अगर ऐसा नहीं होता है तो यह बहुत ही शाब्दिक अर्थों में "नीचे जाना" और "दुर्घटना" होगा।

— वीएलएजी

इसका अर्थ यह लगता है कि DRY को OO की आवश्यकता है, जो निश्चित रूप से सत्य नहीं है। पुन: उपयोग को समान रूप से नि: शुल्क कार्यों, आदि द्वारा सुविधाजनक बनाया जाता है

— अंडरस्कोर

@vlaz जो सच है, लेकिन बात यह है कि एक हवाई जहाज में .... हर कोई तेजी से चलाने की जरूरत है।

— द ग्रेट डक

Answer 8

यह एक नियम नहीं है, यह सिर्फ कुछ दोस्त है जिन्होंने विकिपीडिया की कुछ संख्याओं के साथ पतली हवा से निकाला है और इसे एक नियम कहा है। पेरेटो सिद्धांत के साथ तुलना करें, जो अन्य संदर्भों में अधिक मजबूती से स्थापित है। मैं यह देखना चाहता हूं कि इस "नियम" की सटीकता पर क्या शोध किया गया है (यदि कोई हो)।

लेकिन मूल रूप से आपके प्रश्न का उत्तर है, कुछ कोड अन्य कोड की तुलना में बहुत अधिक बार निष्पादित होते हैं। लू लगना अक्सर इसका कारण होता है। अन्य कारण वेब सेवाओं या भंडारण मीडिया जैसे बाहरी संसाधनों के लिए समय लेने वाली कॉल हैं।

Comments

यह एक वैध बात है कि लोग अंगूठे के नियम के रूप में उपयोग करते हैं।

— द ग्रेट डक

यदि आप सुझाव दे रहे हैं कि यह अंगूठे के एक नियम के रूप में व्यापक उपयोग में है, तो मुझे इसके लिए साक्ष्य देखने में दिलचस्पी होगी! या यह कि अभी तक एक और राय पतली हवा से खींची गई है लेकिन तथ्यात्मक के रूप में निहित है?

— ब्रैड थॉमस

यदि आप वास्तव में विकिपीडिया लेख पढ़ते हैं , तो आप देखेंगे कि प्रश्नकर्ता द्वारा संदर्भित उद्धरण में यह उद्धरण है: amazon.com/Every-Computer-Performance-Book-Computers/dp/… मैंने इसे व्यक्तिगत रूप से कभी उपयोग में नहीं देखा है लेकिन आप पोस्ट के रूप में असभ्य थे और मेरी राय में खारिज कर दिया तो मैंने जवाब दिया। जाहिर है 10% एक संख्या है जिसे किसी ने बनाया है। मैं अपने कार्यक्रम को अकुशल बनाकर जो भी चाहे कर सकता हूं। हालाँकि, यह सॉफ्टवेयर इंजीनियरिंग में उपयोग किया जाने वाला शब्द है या नहीं, यह देखने में स्पष्ट रूप से बहस योग्य नहीं है कि यहाँ कितने लोग इसके अस्तित्व के लिए सहमत हैं।

— द ग्रेट डक

अच्छी तरह से मैं किताब खरीदने के बारे में नहीं हूँ, यह देखने के लिए कि यह कथित तौर पर संदर्भित शोध को देखने के लिए है ... क्या आप इसमें से एक उद्धरण पोस्ट कर सकते हैं जो सबूत दिखाता है? या आप वास्तव में कोई नहीं देखा है?

— ब्रैड थॉमस

@BradThomas: इस सिद्धांत के विरुद्ध कि 90-10 नियम का आविष्कार किसी ने किया था, जो विकिपीडिया का संपादन कर रहा था, यह व्यापक रूप से उद्धृत किया गया था, 90 और 10 की संख्या के साथ, विकिपीडिया के अस्तित्व में आने से कई साल पहले; वास्तविक सिद्धांत यह नहीं है कि वास्तव में कोड का 10% रनटाइम के 90% के लिए है, बल्कि यह है कि अधिकांश कार्यक्रमों में कोड का एक छोटा सा हिस्सा - 10% या उससे कम , रनटाइम के इतने बड़े हिस्से के लिए खाते हैं- -90% या उससे अधिक है कि कोड के उस छोटे हिस्से के प्रदर्शन में 10% सुधार भी बाकी सभी में 1000x सुधार से अधिक संपूर्ण निष्पादन समय को कम करेगा।

— सुपरकैट

Answer 9

यह "पेरेटो सिद्धांत" की पुनर्व्याख्या है, जिसमें कहा गया है, "कई घटनाओं के लिए, लगभग 80% प्रभाव 20% कारणों से आते हैं।", जिसे 80/20 नियम के रूप में भी जाना जाता है। यह नियम ज्यादातर अर्थशास्त्र पर लागू होता है, इसलिए यह समझ में आता है कि इसे प्रोग्रामिंग के लिए फिर से लागू किया जाएगा।

यह सिर्फ एक पैटर्न है जिसे लंबे समय तक देखा गया है।

यहाँ इस तरह के पैटर्न पर एक बहुत अच्छा वीडियो है, और यह भी Pareto सिद्धांत बताते हैं।

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