প্রোগ্রামের অপ্টিমাইজেশনের 90/10 রুলের অর্থ কী?

67

উইকিপিডিয়া অনুসারে, প্রোগ্রাম অপটিমাইজেশনের 90/10 নিয়মতে বলা হয়েছে যে "প্রোগ্রামের প্রয়োগের 90%% কোডের 10% সম্পাদন করতে ব্যয় করা হয়" (দ্বিতীয় অনুচ্ছেদটি এখানে দেখুন )।

আমি সত্যিই এটি বুঝতে পারি না। আসলে এটার অর্থ কি? কোডের কেবল 10% কার্যকর করতে 90% কার্যকর কার্যকর সময় কীভাবে ব্যয় করা যায়? কোডের অন্যান্য 90% সম্পর্কে কী হবে? মাত্র 10% সময়ে কীভাবে তাদের কার্যকর করা যায়?

optimization theory program

— রক্ষীথ রবি
সূত্র

50

কোডের কিছু অংশ অন্যান্য অংশের চেয়ে প্রায়শই কার্যকর করা যেতে পারে। লুপগুলি সর্বোপরি এটির জন্য। বাস্তবে, প্রায় সবসময় কিছু অংশ মৃত্যুদন্ড কার্যকর করা হয় উপায় অন্যদের তুলনায় আরো প্রায়ই।

— কিলিয়ান ফট

147

আপনি সফ্টওয়্যার প্রকল্পের সময়কালের জন্য 90/10 রুলটি না শুনে অপেক্ষা করুন: "প্রকল্পের 90% বরাদ্দ সময়ের প্রথম 90% সময় নেবে; প্রকল্পের শেষ 10% বরাদ্দ সময়ের অন্যান্য 90% গ্রহণ করবে "

— পল ডি ওয়েট

3

এখানে বিভ্রান্তি: "সময় কার্যকর করতে ব্যয় হয়"। বিবেচনা করুন a++; for(i=0;i<100;i++){b++;} for(i=0;i<100;i++){print(xyz);}। নিশ্চিত যে প্রথম ফর্ম-লুপটি প্রথম বিবৃতিটির চেয়ে অনেক বেশি ব্যয় করে তবে দ্বিতীয় ফর-লুপটি প্রথম ফর-লুপের চেয়ে x 1000x বেশি সময় ব্যয় করে তবে কার্যকর হয় না । এটি মুদ্রণের অপেক্ষায় ব্যয় করে । সুতরাং মৃত্যুদন্ড কার্যকর করতে ব্যয় করা সময় এবং কোড এর জন্য দায়ী সময়গুলির মধ্যে পার্থক্য রয়েছে ।

— মাইক ডুনলাভে

32

@ পল_ডি.ওয়েট আমি ভেবেছিলাম যে প্রকল্পের 90% সময় 90% সময় নিয়েছিল, 90% যা বাকি আছে তার 90% বেশি সময় লাগে এবং তাই কোনও প্রকল্প নয় এমন সিদ্ধান্তে একটি অ-কনভার্জেন্ট সিরিজটি অবলম্বন করে অসীম সময়ের চেয়ে কম কখনও শেষ বা সম্পূর্ণ ডি-বাগ হয়েছে।

— নিগেল 222

9

ব্যবহারিক উদাহরণগুলির জন্য, আমি কয়েকটি কোডে কাজ করেছি (বৈজ্ঞানিক মডেল) মডেলটি পড়তে ও সেট আপ করতে প্রচুর পরিমাণ কোড (~ 10 কে লাইন) ব্যবহার করে, তারপরে প্রকৃত গণনা করতে কয়েকশ লাইনের মধ্য দিয়ে একটি লুপ তৈরি করে। তবে সেই সংক্ষিপ্ত লুপটি ছিল এন ^ 4 (তিনটি স্থানের মাত্রা বহুবারের কয়েক হাজার পদক্ষেপের মধ্য দিয়ে পুনরাবৃত্তি হয়েছিল), তাই গণনা করতে বেশ কয়েকদিন সময় লেগেছিল। সুতরাং প্রকৃত অনুপাতটি সম্ভবত 99% / 1% :-) এর মতো ছিল

— jamesqf

184

এখানে দুটি মূল নীতি রয়েছে:

কিছু কোড অন্যান্য কোডের চেয়ে অনেক বেশি কার্যকর হয়। উদাহরণস্বরূপ, কিছু ত্রুটি পরিচালনার কোড কখনও ব্যবহার করা যাবে না। আপনি যখন আপনার প্রোগ্রাম শুরু করবেন তখনই কিছু কোড কার্যকর করা হবে। আপনার প্রোগ্রামটি চলাকালীন অন্যান্য কোড বারবার কার্যকর করা হবে।
কিছু কোড অন্যান্য কোডের তুলনায় চালাতে অনেক বেশি সময় নেয় । উদাহরণস্বরূপ, একটি একক লাইন যা একটি ডাটাবেসে কোয়েরি চালায়, বা ইন্টারনেট থেকে একটি ফাইল টানতে সম্ভবত লক্ষ লক্ষ গাণিতিক ক্রিয়াকলাপের চেয়ে বেশি সময় লাগবে।

90/10 রুলটি আক্ষরিকভাবে সত্য নয়। এটি প্রোগ্রাম অনুসারে পরিবর্তিত হয় (এবং আমি সন্দেহ করি যে 90 এবং 10 এর নির্দিষ্ট সংখ্যার কোনও ভিত্তি আছে; কেউ সম্ভবত এগুলি পাতলা বায়ু থেকে টেনে নিয়ে গেছে)। তবে মুল বক্তব্যটি হ'ল যদি আপনার প্রোগ্রামটি দ্রুত চালনার প্রয়োজন হয় তবে সম্ভবত এটি সংখ্যক লাইনই সংঘটিত হওয়ার জন্য তাৎপর্যপূর্ণ। আপনার সফ্টওয়্যারটির ধীর অংশগুলি চিহ্নিত করা প্রায়শই অপ্টিমাইজেশনের বৃহত্তম অংশ।

এটি একটি গুরুত্বপূর্ণ অন্তর্দৃষ্টি, এবং এর অর্থ হ'ল যে সিদ্ধান্তগুলি নতুন বিকাশকারীকে বিপরীত বলে মনে হয় প্রায়শই সঠিক হতে পারে। উদাহরণ স্বরূপ:

প্রচুর কোড রয়েছে যে এটি বোবা, সরল পদ্ধতিতে জিনিসগুলি করা হলেও "আরও ভাল" করা আপনার সময়ের পক্ষে উপযুক্ত নয় । এক্সওয়াইজেড অ্যাপ্লিকেশনটির জন্য আপনি আরও দক্ষ অনুসন্ধান অ্যালগরিদম লিখতে পারেন? হ্যাঁ, তবে প্রকৃতপক্ষে প্রতিটি মানের একটি সাধারণ তুলনা হাজার হাজার মান থাকা সত্ত্বেও একটি ক্ষুদ্র পরিমাণে সময় নেয়। সুতরাং এটি ঠিক মূল্য নয়। নতুন বিকাশকারীদের জন্য অপ্রয়োজনীয় অপ্টিমাইজেশন এড়ানো শক্ত হয়ে উঠতে পারে, কারণ তাদের ডিগ্রি প্রোগ্রামে "সঠিক" (যার অর্থ সবচেয়ে দক্ষ) এলগরিদম লেখার জন্য এতটা সময় ব্যয় করা হয়েছিল। কিন্তু বাস্তব বিশ্বে, সঠিক অ্যালগরিদম এমন কোনও একটি যা কার্যকরভাবে কাজ করে এবং দ্রুত চালায়।
আপনার কোডটি আরও দীর্ঘ এবং আরও জটিল করে তোলে এমন পরিবর্তনগুলি এখনও পারফরম্যান্সের জয় হতে পারে। উদাহরণস্বরূপ, অ্যাপ্লিকেশন এফও-তে এটি কেবল একটি একক ডাটাবেস কল এড়ানোর জন্য কয়েকশ লাইন নতুন যুক্তি যুক্ত করার উপযুক্ত হতে পারে।

6

বিশেষ দ্রষ্টব্য, বাছাইয়ের কাজগুলির মতো জিনিসগুলির সাথে, এটি একটি মার্জিত আলগো সম্পূর্ণরূপে কার্যকরী এবং বগল না পেয়ে কোনও মূককে সহজ অ্যালগো সব ক্ষেত্রে সঠিক কাজ করা সহজ এবং আরও সহজ। (অ্যাকাদামিয়ার বাইরে ধরণের লেখার একমাত্র কারণ হ'ল আপনি যদি কোনও লাইব্রেরি তৈরি করছেন বা প্লাটফর্ম ছাড়াই কাজ করছেন…)

— স্টারওয়েভার

5

আমি মনে করি আপনার লিঙ্কটি shouldioptimize.com এ যুক্ত করা দরকার :)

— ইভান কলমিচেক

13

আমি মনে করি 90/10 সুপরিচিত 80/20 Pareto নীতি থেকে আসে en.wikipedia.org/wiki/Pareto_principle

— fernando.reyes

2

@ স্টারওয়েভার এই কারণেই যে ভাষাগুলি লেখাগুলি একটি দক্ষ বাবল্ড-বাছাইয়ের চেয়ে সহজ বা সহজতর রচনা তৈরি করে সেখানে সি ++ এর মতো গুরুত্বপূর্ণ। এই জাতীয় "প্রিপেইকেজড" অ্যালগরিদম এবং কোড ব্যবহারের স্থানে জটিলতা সৃষ্টি না করে সত্যই ভারী অনুকূলিত করা যেতে পারে।

— ইয়াক্ক

6

@ ইভানকোলমিচেক site সাইটটি বিভ্রান্তিকর। অবশ্যই, ব্যয় বিশ্লেষণের এই ধরণের একটি বিষয় বিবেচনা করা উচিত তবে ব্যবহারকারীর অভিজ্ঞতার মতো অন্যান্য কারণও রয়েছে। আপনি অপ্টিমাইজ না করে প্রচুর অর্থ সাশ্রয় করতে পারেন, তবে লোকেরা যদি হতাশ হয়ে আপনার সাইট ছেড়ে যায় তবে আপনি প্রচুর উপার্জনও হারাতে পারেন।

— jpmc26

21

এটি প্রকৃতির কোনও আইন নয়, তবে বিস্তৃত অভিজ্ঞতার দ্বারা উত্সর্গিত একটি আঙ্গুলের নিয়ম। এটি ৮০/২০ বিধি হিসাবেও পরিচিত এবং এটি কেবল সর্বদা মোটামুটি।

লুপস, শাখা এবং অন্যান্য প্রবাহ নিয়ন্ত্রণ।

প্রতিটি জায়গাতে যদি একটি আইফ থাকে, আপনার একটি শাখা থাকবে যা অন্য শাখার তুলনায় প্রায়শই নেওয়া হয়। সুতরাং মৃত্যুদন্ড কার্যকর করার সময়টির আরও বেশি অংশ প্রোগ্রামটির অংশটি কার্যকর করতে ব্যয় করা হয়, অন্য অংশটি নয়।

প্রতিটি জায়গাতে লুপ রয়েছে যা একাধিকবার চলে, আপনার কাছে এমন কোড রয়েছে যা পার্শ্ববর্তী কোডের চেয়ে বেশি কার্যকর হয় exec এভাবে আরও সময় ব্যয় হয় সেখানে।

উদাহরণ হিসাবে বিবেচনা করুন:

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

এখানে উইলটি print("Oh No!")কেবল সর্বদা সর্বোচ্চ একবার চালায় এবং প্রায়শই কখনও হয় না, তবে DoWork(i)প্রায় এক মিলিয়ন বার ঘটবে।

— Caleth
সূত্র

7

এটিকে 80/20 নিয়ম বললে পেরেটো নীতিটি বিভ্রান্তি সৃষ্টি করতে পারে যা কেবল প্রোগ্রামিংয়ের চেয়ে বেশি বিস্তৃতভাবে প্রযোজ্য। হতে পারে 90 এবং 10 কেবল সুবিধাজনক সংখ্যা যার অর্থ এই ওভারল্যাপটি নেই।

— ট্রিকোপলাক্স

29

এটি পেরেটো অধ্যক্ষের উদাহরণ। উভয় জোড়া সংখ্যাই সমানভাবে নির্বিচারে

— কালেথ

2

পেরেটো নীতিতে 80/20 বিভাজনের গাণিতিক ভিত্তি রয়েছে। তারা "প্রচুর" এবং "কিছুটা" উপস্থাপনের জন্য কেবল কিছু কাল্পনিক ব্যক্তিত্ব নয়।

— ময়লি

1

@ ময়লি - হ্যাঁ, "৮০/২০ বিভাজনের গাণিতিক ভিত্তি আছে ...", কিন্তু বাস্তব বিশ্বে এটি কখনই (ঠিক আছে, কাকতালীয়ভাবে, খুব কমই) ঠিক ৮০/২০ হতে পারে না।

— কেভিন ফেগান

2

@ থ্রিচোপ্লেক্স প্যারেটো নীতিটি এখানে খুব ভালভাবে প্রযোজ্য। 20% কারণের (কোড লাইনগুলি) 80% এর প্রভাব (রানটাইম)

— njzk2

16

Loops।

আমি সেখানে থামার জন্য প্রলুব্ধ! :-)

এই প্রোগ্রাম বিবেচনা করুন

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% নেয় takes

বৃহত্তর আরও বাস্তব বিশ্বের উদাহরণ সহ এটি বেড়ে যায় তাই রান-টাইমের বেশিরভাগ অংশের জন্য খুব অল্প পরিমাণে রেখা থাকে।

90/10 রুল (বা এটি কখনও কখনও 80/20 হিসাবে দেওয়া হয়) একটি "থাম্বের নিয়ম" - এটি প্রায় সত্য।

পেরেটো নীতিও দেখুন

— নিক কেইগলি
সূত্র

2

এটি প্রায় আনুমানিক সত্য বলার পরিবর্তে আমি বলব যে অনেক ক্ষেত্রে, কমপক্ষে 90% সময়টি কোডের একটি ক্ষুদ্র ভগ্নাংশ নির্বাহ করতে ব্যয় করা হবে - সর্বাধিক 10%। স্পষ্টতই এমন প্রোগ্রামগুলি করা সম্ভব হবে যেখানে সমস্ত অংশ একই পরিমাণ নির্বাহের সময় ব্যয় করেছিল, তবে এটি বিরল।

— সুপারক্যাট

পেরেটো নীতি উল্লেখ করার জন্য +1। এই গভীর ভাসস ভিডিওতে আরও গভীরতার ব্যাখ্যা দেখা যায় ।

— রাদু মুর্জিয়া

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% সময় আপনি কিছু সিঙ্গল-পাস গণনা করেন।

আর একটি উদাহরণ হ'ল কিছু এইচএ পরিষেবাতে ত্রুটি পরিচালনা করা। যে কোনও উচ্চ-উপলভ্য পরিষেবাটি সাধারণ পরিস্থিতিতে অসীম পরিমাণ সময় কাজ করার জন্য ডিজাইন করা হয়েছে । এটি সাধারণত 99% সময় পরিচালনা করে তবে মাঝে মাঝে ত্রুটির ক্ষেত্রে এটি কিছু ত্রুটি পরিচালনা ও পুনরুদ্ধার চালায় যা সার্ভিসের চেয়েও যুক্তিগতভাবে জটিল হতে পারে।

— সার্জি
সূত্র

ভাল লাগল, আমি আশা করছিলাম যে কেউ এই চরম উদাহরণটি পোস্ট করবে, এটি তাত্পর্যটি পরিষ্কারভাবে দেখায়।

— djechlin

3

90/10 টি যুক্তি মানে আপনার কোডের একটি ছোট্ট অংশ পুনরাবৃত্তি হবে বা অন্যদের চেয়ে বেশি ব্যবহৃত হবে। এটি প্রায়শই পরামর্শ দেওয়ার জন্য ব্যবহার করা হয় যে আপনার কোডের এই 10% টি ক্ষেত্রে আপনার 90% বিকাশ / অনুকূলকরণের প্রচেষ্টাতে মনোনিবেশ করা উচিত।

মাইক্রোসফ্ট ওয়ার্ড বা ওপেনঅফিসের মতো একটি সাধারণ পাঠ্য প্রসেসর ভাবেন :

পছন্দগুলি ডায়ালগ, বেশি ব্যবহৃত হয় না;
অক্ষরগুলি আঁকতে থাকা সাবরুটাইনগুলি সর্বদা ব্যবহৃত হয়।

এই উক্তিটি ম্যানেজমেন্ট সায়েন্সেও ব্যবহৃত হয় ... এটি জীবন নিজেই একটি পাঠ ... অর্থ: আপনার প্রচেষ্টাকে সর্বাধিক মনোনিবেশ করুন যেখানে আপনাকে আরও ফলাফল দেয়।

— লুকাস
সূত্র

6

মাইক্রোসফ্ট ওয়ার্ডটি যদি সহজ হয় তবে জটিলটির উদাহরণ কী?

— পিটার মর্টেনসেন

পছন্দ করেছেন

— গ্রেট ডাক

স্পষ্টভাবে, পিটারমোরটেনসেন ইম্যাক্স

— مورু

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 টি লাইন রয়েছে এখানে 11 টির মধ্যে 3 লুপের জন্য লক্ষ্য করুন যেখানে কোডটি না দিয়ে এই ছোট্ট টুকরোটির জন্য কত সময় ব্যয় করা হবে? বেশ কিছুটা সময় যখন অন্য 8 টি লাইন কেবলমাত্র একটি একক অক্ষর মুদ্রণ করছে। সুতরাং, সাবধান থাকুন যে কোনও কোড সংক্ষিপ্ত থাকতে পারে, এটি আপনাকে কতবার কার্যকর করা হয় এবং কত সময় নিবে তা আপনাকে জানায় না।

— জেবি কিং
সূত্র

0

অন্যান্য দুর্দান্ত উত্তরের দ্বারা উল্লিখিত লুপিংয়ের পাশাপাশি, DRY নীতিগুলিও বিবেচনা করা উচিত। ভাল লিখেছেন, অবজেক্ট ওরিয়েন্টড কোডটিতে প্রচুর পুনরায় ব্যবহারযোগ্য অংশ রয়েছে। সংজ্ঞা অনুসারে যে অংশগুলি পুনঃব্যবহার করা হয় সেগুলি কমপক্ষে দ্বিগুণ ব্যবহৃত হয় যা কেবল একবার কার্যকর করা হয়। আপনার যদি প্রচুর ওও কোড থাকে তবে আপনি সম্ভবত কয়েকটি ক্লাস এবং পদ্ধতিগুলি বহুবার এবং কোডের কয়েকটি অন্যান্য টুকরো কেবল একবার পুনরায় ব্যবহার করতে পারেন।

অন্যান্য উত্তরে যেমন উল্লেখ করা হয়েছে, কেবলমাত্র একবার ব্যবহার করা কোডটি উন্নত করার চেয়ে কোডটি ব্যবহার করার ক্ষেত্রে ব্যয় করা ভাল।

— মার্শাল টাইগারাস
সূত্র

2

আপনি প্রচুর কোড পুনরায় ব্যবহার করতে পারেন, তবে এগুলির সবগুলিই খুব কমই কার্যকর করা যেতে পারে (এখনও গুরুত্বপূর্ণ হলেও)।

— পিটার মর্টেনসেন

@ পিটারমোরটেনসেন "গুরুত্বপূর্ণ তবে প্রায়শই" একই রকম হয় না "প্রায় প্রতি সেকেন্ডে পুনরায় ব্যবহার করা হয় এবং যত তাড়াতাড়ি সম্ভব দ্রুত হওয়া প্রয়োজন"

— দ্য গ্রেট ডাক ২

@ দ্য গ্রেটডাক এবং আমি মনে করি না যে এটাই তার অর্থ ছিল। কারণ আপনার কাছে এমন কোড থাকতে পারে যা খুব বেশি সময় কার্যকর হয় তবে আপনি এটি যত তাড়াতাড়ি ঘটতে চান। উদাহরণস্বরূপ, আসুন ত্রুটি পুনরুদ্ধার করা যাক - অ্যাপ্লিকেশনটির উপর নির্ভর করে সিস্টেমটি আবার চালু হওয়ার জন্য কিছু সময় (5 মিনিট, এক ঘন্টা, সম্ভবত আরও কিছু) নেওয়া ভাল fine তবে, যদি বলুন, একটি ফ্লাইট সিস্টেমের মধ্যে একটি ত্রুটির মুখোমুখি হয়, আপনি সত্যিই এটি যত তাড়াতাড়ি সম্ভব এটি চান। কারণ এটি যদি না হয় তবে এটি "আস্তে আস্তে" নেমে যাবে এবং খুব আক্ষরিক অর্থে "ক্র্যাশ" হবে।

— VLAZ

এর থেকে বোঝা যাচ্ছে যে ডিআরওয়াইয়ের ওও দরকার, যা অবশ্যই সত্য নয়। পুনরায় ব্যবহার ফ্রি ফাংশন ইত্যাদির মাধ্যমেও সমানভাবে সহজলভ্য

— আন্ডারস্কোর_আডি

@ ভ্লাজ এটি সত্য, তবে জিনিসটি হ'ল একটি বিমানের মধ্যে .... প্রত্যেকটি দ্রুত চালানো দরকার।

— দ্য গ্রেট ডাক

0

এটি কোনও নিয়ম নয়, কেবলমাত্র এমন কিছু বংশধর, যিনি কয়েক নম্বর সংখ্যক উইকিপিডিয়া সম্পাদনা করেছেন এবং এটিকে একটি নিয়ম বলে অভিহিত করেছেন। পেরেটো নীতিমালার সাথে তুলনা করুন, যা অন্যান্য প্রসঙ্গে আরও দৃ firm়ভাবে প্রতিষ্ঠিত। আমি দেখতে চাই এই "বিধি" এর যথার্থতার বিষয়ে কী গবেষণা হয়েছে (যদি থাকে)।

তবে মূলত আপনার প্রশ্নের উত্তরটি হ'ল, কিছু কোড অন্যান্য কোডের চেয়ে অনেক বেশি ঘন ঘন কার্যকর হয়। লুপগুলি প্রায়শই এটির কারণ হয়। অন্যান্য কারণগুলি সময় সাশ্রয়ী কলগুলি যেমন ওয়েব পরিষেবা বা স্টোরেজ মিডিয়া যেমন বাহ্যিক সংস্থানগুলিতে।

— ব্র্যাড থমাস
সূত্র

এটি একটি বৈধ জিনিস যা লোকেরা থাম্বের বিধি হিসাবে ব্যবহার করে।

— গ্রেট ডাক

আপনি যদি পরামর্শ দিচ্ছেন যে এটি থাম্বের নিয়ম হিসাবে ব্যাপকভাবে ব্যবহৃত হয়, তবে আমি তার প্রমাণও আগ্রহী হতে চাই! বা এটি এখনও অন্য মতামত সরু বায়ু থেকে টানা কিন্তু বাস্তব হিসাবে বোঝানো হয়েছে?

— ব্র্যাড থমাস

আপনি যদি উইকিপিডিয়া নিবন্ধটি বাস্তবে পড়ে থাকেন তবে আপনি দেখতে পাবেন যে প্রশ্নকর্তার দ্বারা উল্লেখ করা উদ্ধৃতিটির উদ্ধৃতিটি রয়েছে: অ্যামাজন / সব কম্পিউটার / পারফরম্যান্স-বুক-কম্পিউটার / ডিপি / I've আমি ব্যক্তিগতভাবে কখনও এটি ব্যবহারে দেখিনি, তবে আপনার পোস্টটি আমার মতামতকে অভদ্র এবং প্রত্যাখ্যান হিসাবে প্রকাশিত হয়েছে তাই আমি প্রতিক্রিয়া জানালাম। স্পষ্টতই 10% এমন একটি সংখ্যা যার দ্বারা তৈরি। আমি আমার প্রোগ্রামটি অকার্যকর করে এটিকে যেকোন নম্বর করতে চাই। তবে, এটি সফটওয়্যার ইঞ্জিনিয়ারিংয়ে ব্যবহৃত একটি শব্দ কিনা তা এখানকার কত মানুষ এর অস্তিত্বের সাথে সম্মত তা স্পষ্টভাবে বিতর্কযোগ্য নয় seeing

— দ্য গ্রেট ডাক

ঠিক আছে, আমি কেবল গবেষণাটি অনুমান করে যে গবেষণাটি দেখছে তা দেখার জন্য বইটি কিনতে যাচ্ছি না ... আপনি কি এটি থেকে একটি উদ্ধৃতি পোস্ট করতে পারেন যা প্রমাণটি দেখায়? নাকি বাস্তবে কেউ দেখেনি?

— ব্র্যাড থমাস

1

@ ব্র্যাডথোমাস: উইকিপিডিয়া সম্পাদনাকারী যে কেউ 90-10 বিধি উদ্ভাবন করেছিলেন এই তত্ত্বের বিরুদ্ধে প্রমাণ হ'ল উইকিপিডিয়া থাকার বহু বছর আগে 90 এবং 10 সংখ্যার সাথে এটির ব্যাপকভাবে উদ্ধৃতি দেওয়া হয়েছিল; আসল নীতিটি কোডের ঠিক 10% রানটাইমের 90% অংশের জন্য নয়, বরং বেশিরভাগ প্রোগ্রামে কোডের একটি ছোট অংশ - 10% বা তারও কম , রানটাইম- এর এত বড় অংশের জন্য অ্যাকাউন্টগুলি -90% বা তারও বেশি যে কোডটির সেই ছোট্ট অংশের কর্মক্ষমতাতে 10% উন্নতিও সামগ্রিক প্রয়োগের সময়টিকে অন্য সমস্ত কিছুতে 1000x উন্নয়নের চেয়ে কমিয়ে দেবে।

— সুপারক্যাট

0

এটি "পেরেটো নীতি" এর পুনরায় ব্যাখ্যা, যা বলেছে "অনেক ঘটনার জন্য প্রায় 80% এর প্রভাব 20% কারণ থেকে আসে।", এটি 80/20 বিধি হিসাবেও পরিচিত। এই নিয়মটি বেশিরভাগ ক্ষেত্রে অর্থনীতিতে প্রয়োগ করা হয়, সুতরাং এটি বোধগম্য হয় যে এটি প্রোগ্রামিংয়ের জন্য পুনরায় তৈরি করা উচিত।

এটি কেবল একটি নিদর্শন যা দীর্ঘ সময় ধরে পর্যবেক্ষণ করা হয়েছে।

এর মতো নিদর্শনগুলির জন্য এখানে খুব সুন্দর একটি ভিডিও এবং এটি পেরেটো নীতিমালাও ব্যাখ্যা করে।

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

— imnota4
সূত্র