অপ্টিমাইজেশন কখন অকাল হয় না এবং তাই মন্দ হয় না?

Question

"অকালীন অপটিমাইজেশন হ'ল সমস্ত অশুভের মূল" আমাদের মধ্যে প্রায় সকলেই শুনে / শুনেছেন। আমি কী কৌতূহল বোধ করি কোন ধরণের অপ্টিমাইজেশন অকাল নয়, অর্থাত্ সফটওয়্যার বিকাশের প্রতিটি পর্যায়ে (উচ্চ স্তরের নকশা, বিস্তারিত নকশা, উচ্চ স্তরের বাস্তবায়ন, বিশদ বাস্তবায়ন ইত্যাদি) অন্ধকারের দিকে না গিয়ে আমরা কী অপ্টিমাইজেশনের সীমাটি বিবেচনা করতে পারি।

Comments

আরও দেখুন প্রোগ্রামারস.স্ট্যাকেক্সেঞ্জার.কম

— রবার্ট হার্ভে

আরও দেখুন: কোডিংয়ের সময় মাইক্রো-অপ্টিমাইজেশন কী গুরুত্বপূর্ণ?

— gnat

Answer 1

আপনি যখন অভিজ্ঞতাটি বন্ধ করছেন? মন্দ নয়। "যতবারই আমরা এক্স করেছি, আমরা একটি নৃশংস পারফরম্যান্স হিট করেছি। এবার এক্সকে পুরোপুরি অনুকূল করা বা এড়িয়ে চলার পরিকল্পনা করি plan"

তুলনামূলকভাবে বেদাহীন হলে? মন্দ নয়। "এটিকে ফু বা বার হিসাবে প্রয়োগ করা ঠিক ততটাই কাজ গ্রহণ করবে, কিন্তু তাত্ত্বিকভাবে, বারটি আরও অনেক দক্ষ হওয়া উচিত Let's আসুন এটি বার করি।"

যখন আপনি ক্রেপি অ্যালগরিদমগুলি এড়িয়ে যাচ্ছেন যেগুলি ভয়াবহভাবে স্কেল হবে? মন্দ নয়। "আমাদের প্রযুক্তির নেতৃত্ব বলেছে যে আমাদের প্রস্তাবিত পথ নির্বাচনের অ্যালগরিদম ফ্যাক্টরিয়াল সময়ে চলে; তার অর্থ কী তা আমি নিশ্চিত নই, তবে তিনি পরামর্শ দিয়েছিলেন যে আমরা সেপুকুকেও এটি বিবেচনা করার জন্য প্রতিশ্রুতিবদ্ধ করেছি। আসুন অন্য কিছু বিবেচনা করুন।"

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

---

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

Comments

কখনও কখনও, খুব সহজেই একটি কল্পিত সমস্যা সমাধান করা এখনও হালকা দুষ্টু, কারণ এর ফলে কোড পড়া বজায় রাখা আরও শক্ত, পড়া আরও শক্ত হতে পারে। খুব কঠিন নয় (বা এটি একটি সহজ সমাধান হবে না), তবে সম্ভবত মাঝে মধ্যে এখনও প্রাসঙ্গিক। উদাহরণস্বরূপ একটি চৌকস বিটওয়াইজ ট্রিক ব্যবহার করা হতে পারে যা কিছু লোক চিনতে পারে না এবং কোনটি সংকলক সম্ভবত কার্যকরভাবে তা প্রয়োগ করবে।

— স্টিভ 314

আমি এখানে স্টিভের সাথে একমত, কখনও কখনও "অপ্টিমাইজেশন" কেবল এটির পক্ষে উপযুক্ত হয় না, বিশেষত কারণ সংকলকগুলি খুব ভাল। উদাহরণ? যদি iস্বাক্ষরবিহীন হয়, i / 2দ্বারা প্রতিস্থাপিত হতে পারে i >> 1। এটা দ্রুত। তবে এটি আরও রহস্যজনক (সকলেই এর প্রভাব দেখতে পাবেন না, এমনকি যারা করেন তারাও সময় হারাতে পারেন)। তবে এর মধ্যে সবচেয়ে খারাপটি এটি হ'ল যে সংকলকটি যাইহোক এটি করবে, তবে উত্স কোডটি কেন অবজ্ঞা করবে;)?

— ম্যাথিউ মিঃ

@ ল্যারি: আমি করিনি, সুতরাং অনুমান করি এটির একটি ভাল উদাহরণ।

— জোরিস মেজ

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

— বার্ট ভ্যান ইনজেন শেনৌ

@ ম্যাথু: তাদের কী শেখাবেন? নোংরা এবং অপ্রয়োজনীয় কৌশল? কেন? প্রোফাইলিং যদি দেখায় যে একটি i/2সত্যই একটি গরম জায়গা এবং এটি (অবিশ্বাস্য, তবে ধরে নেওয়া যাক) i>>1এটি দ্রুততর করে তোলে, তাই এটি করুন এবং এটিতে একটি মন্তব্য দিন যে এই প্রোফাইলটি দেখিয়েছে যে এটি দ্রুত। যদি সত্যই এটির যে কোনও জায়গায় প্রয়োজন হয় (যা আমি সন্দেহ করি, যেহেতু ম্যাথিউই বলেছিলেন, সংকলকরা এগুলি করার জন্য যথেষ্ট স্মার্ট হওয়া উচিত), নবীনীরা কিছু শিখবে, যদি তা না হয় (যা সম্ভবত) তবে আপনি কেন প্লাগ করতে চান? তাদের মাথাবিহীন লোককাহিনী নিয়ে?

— এসবিআই

Answer 2

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

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

Comments

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

— সুপারক্যাট

দুঃখিত, তবে সন্দেহজনকভাবে ওভাররেঞ্জাইনিংয়ের মতো "সমস্ত ক্ষেত্রে ভাল থাকুন" শোনাচ্ছে। এছাড়াও, এটি সম্ভবত বাস্তবসম্মত নয় - জীবন সর্বদা ট্রেড অফস সম্পর্কে।

— সলেসকে

নকশা পর্যায়ে জোর দেওয়ার জন্য +1; আপনি যদি ইচ্ছাকৃতভাবে এর সুবিধাগুলি ওজন করেন তবে এটি অকাল নয়।

— নাথান টগি

বিপরীতে, আপনার লাইব্রেরিটি কীভাবে ব্যবহৃত হবে তা আপনি যদি কখনই জানেন না তবে এটির উন্নতিতে সময় ব্যয় করার কোনও ব্যবসায়ের মূল্য আছে কিনা তা আপনি জানেন না। সুতরাং এটি একটি যুক্তি খুব কমই।

— রিমকো গ্রিলিচ

Answer 3

কোন ধরণের অপ্টিমাইজেশন [অচল) নয়

পরিচিত সমস্যাগুলির ফলস্বরূপ যে ধরণের আসে।

Answer 4

অপ্টিমাইজেশন কখন অকাল হয় না এবং তাই মন্দ হয় না?

ভাল কি মন্দ তা বলা মুশকিল। কার অধিকার আছে? আমরা যদি প্রকৃতির দিকে তাকাই তবে মনে হয় আমাদের বেঁচে থাকার একটি বিস্তৃত সংজ্ঞা সহ আমাদের বেঁচে থাকার জন্য প্রোগ্রাম করা হয়েছে যার মধ্যে আমাদের জিনকে বংশধরতে যাওয়ার অন্তর্ভুক্ত রয়েছে।

সুতরাং আমি বলব, কমপক্ষে আমাদের বেসিক ফাংশন এবং প্রোগ্রামিং অনুসারে, প্রজননের লক্ষ্যটির সাথে যখন সারিবদ্ধ হয় তখন সেই অনুকূলকরণটি মন্দ হয় না evil ছেলেদের জন্য, blondes, ব্রুনেটস, লাল মাথা, অনেক মনোরম আছে। মেয়েদের জন্য, ছেলে রয়েছে এবং তাদের মধ্যে কিছু ঠিক আছে বলে মনে হয়।

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

Comments

কেউ এই পুরানো বুক বাদামে নতুন করে নিয়ে আসা দেখে সতেজ হয়। এটি যা লাগে তা হ'ল নুথের পুরো উক্তিটি পড়ুন, এবং কেবল একটি বাক্য নয়, তাই না?

— রবার্ট হার্ভে

@ রবার্টহারভে আমার এখানে কিছুটা পোষা প্রাণীর উঁকি আছে - যেহেতু অনেকের মনে হয় কেবল একটি বাক্য উদ্ধৃত করা হয়েছে, এবং এত গুরুত্বপূর্ণ প্রসঙ্গে তথ্য প্রক্রিয়ায় হারিয়ে যেতে চলেছে। আমি নিশ্চিত নই যে, আমি বাচ্চা বাচ্চা পেয়েছি it's :-D

Answer 5

পূর্ণ উদ্ধৃতি সংজ্ঞায়িত যখন অপ্টিমাইজেশান অকাল নয়:

একজন ভাল প্রোগ্রামারকে এ জাতীয় যুক্তি দ্বারা আত্মতুষ্টিতে প্রবৃত্ত করা হবে না, তিনি সমালোচনামূলক কোডটি মনোযোগ সহকারে দেখার পক্ষে হবে; তবে কেবলমাত্র সেই কোডটি সনাক্ত করার পরে । [জোর আমার]

আপনি সমালোচনামূলক কোডটি বিভিন্ন উপায়ে সনাক্ত করতে পারেন: সমালোচনামূলক ডেটা স্ট্রাকচার বা অ্যালগরিদম (যেমন ভারী ব্যবহার করা হয় বা প্রকল্পের "কোর") বড় অপ্টিমাইজেশান দিতে পারে, অনেকগুলি ছোটখাট অপ্টিমাইজেশন প্রোফাইলারের মাধ্যমে সনাক্ত করা হয় ইত্যাদি।

Comments

হ্যাঁ ... এলোমেলো ফাংশন কল করার সময় 90% শেভ করা ঠিক আছে এবং ভাল, তবে আপনার অ্যাপ্লিকেশনটি আসলে তার 80% সময় ব্যয় করে এমন কোডটি দেখে আপনি আরও বেশি প্রভাব ফেলতে পারেন সেখানে কয়েক শতাংশ।

Answer 6

আপনার অভিজ্ঞতার উপর ভিত্তি করে আপনার সব ক্ষেত্রে একটি "যথেষ্ট যথেষ্ট" সমাধান নির্বাচন করা উচিত।

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

এর অর্থ হ'ল আপনার একটি সুপার কমপ্লেক্সটি বেছে নেওয়া উচিত নয় "যখন 100 ডিবিতে স্বচ্ছভাবে অদলবদল করে 100 জিবি ফাইলগুলি বাছাই করতে পারেন" যখন একটি সর্ট বাছাই হবে তখন বাছাই করার রুটিন, তবে আপনার প্রথম স্থানটিতে সর্ট বাছাইয়ের জন্যও একটি ভাল পছন্দ করা উচিত। অন্ধভাবে বাবল বাছা বাছাই করুন বা "এন্ট্রি সমস্ত এন্ট্রি এলোমেলোভাবে চয়ন করুন এবং সেগুলি ক্রমযুক্ত কিনা তা দেখুন। পুনরাবৃত্তি করুন।" খুব কমই ভাল।

Answer 7

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

Answer 8

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

ঠিক কোথায় পারফরম্যান্স বাধা আছে তা জানাও গুরুত্বপূর্ণ - কোডটির এমন একটি অংশকে অনুকূলকরণ করা যা চালানোর জন্য মোট সময়ের মাত্র 5% সময় নেয় তবে কোনও ভাল করতে পারে না।

পদক্ষেপ 2 এবং 3 অ-অকাল অপটিমাইজেশন বর্ণনা করে:

1. এটাকে সফল কর
2. পরীক্ষা করুন। পর্যাপ্ত দ্রুত না? এটি প্রোফাইল ।
3. পদক্ষেপ 2 থেকে ডেটা ব্যবহার করে কোডের সবচেয়ে ধীর অংশগুলি অনুকূলিত করুন।

Comments

আপনি পদক্ষেপ 0 ভুলে গেছেন যা হ'ল: অ্যাপ্লিকেশনটি ঠিকঠাক করুন যাতে আপনি শুরু থেকেই যুক্তিসঙ্গত কর্মক্ষমতা আশা করতে পারেন।

— রবার্ট হারভে

আমি কেবল কার্যকর বাস্তবায়ন পর্ব সম্পর্কে বলছিলাম।

— গোরগি কোসেভ

আমি পদক্ষেপ # 3 -কে প্রশ্ন করি - খুব প্রায়শই সর্বোত্তম উত্তর হ'ল কোনও ভিন্ন পদ্ধতির সন্ধান করা যাতে আপনি প্রথমে কোডটির ধীর গতিটি করছেন না।

— লরেইন পেচটেল

সঠিক ডেটা স্ট্রাকচার চয়ন করুন।

— জেসনক

Answer 9

যেগুলি পরিবর্তন করা শক্ত যেমন উদাহরণস্বরূপ: হার্ডওয়্যার প্ল্যাটফর্মটি বাছাই করার সময় এটি অপ্টিমাইজেশন নয়।

ডেটা কাঠামো বাছাই একটি ভাল উদাহরণ - কার্যকরী এবং অ-কার্যকরী (কার্য সম্পাদন) উভয় প্রয়োজনীয়তা পূরণের জন্য সমালোচনা critical সহজে পরিবর্তন হয়নি এবং তবুও এটি আপনার অ্যাপ্লিকেশনটিতে থাকা সমস্ত কিছু চালিয়ে যাবে। আপনার ডেটা স্ট্রাকচারগুলি অ্যালগরিদমগুলি উপলভ্য ইত্যাদি পরিবর্তন করে etc.

Answer 10

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

এখানে বেশিরভাগ লোকেরা যে ভুল করেন তা এখানে: তারা প্রোগ্রামটি চালানোর আগেই এটি অপ্টিমাইজ করার চেষ্টা করে। তারা প্রোগ্রামিং একটি কোর্স নিয়েছি থাকেন (অধ্যাপক কে করেনি থেকে আসলে অনেক ব্যবহারিক অভিজ্ঞতা আছে) তারা বড় হে রঙ্গিন চশমা থাকবে এবং তারা যে কি এটা বলে মনে করতে সব সম্পর্কে । এটি সমস্ত একই সমস্যা, পূর্ব অপ্টিমাইজেশন। **

কেউ বলেছেন: প্রথমে এটি ঠিক করুন, তারপরে এটি দ্রুত করুন। তারা সঠিক ছিলেন.

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

সুতরাং এই নির্বোধ বিতর্কগুলি এগিয়ে চলে :)

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

Answer 11

যখন প্রয়োজনীয়তা বা বাজার নির্দিষ্টভাবে এটি জিজ্ঞাসা করে।

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

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

Answer 12

পারফরম্যান্সের কারণে সিস্টেমের "নরম ব্যর্থতা" (এটি কাজ করে তবে এটি এখনও বেহুদাবি) নয় এমন কোনও কিছুকে অপ্টিমাইজ করে যদি বেশিরভাগ লোক অপ্টিমাইজেশনের অকালকে ডেকে আনে।

বাস্তব বিশ্বের উদাহরণ।

• যদি আমার বুদ্বুদ সাজানোর জন্য 20 মিমি সময় লাগে তবে এটি 1 মিমি কুইকোর্টে অনুকূলিতকরণে 2000% কর্মক্ষমতা বৃদ্ধি থাকা সত্ত্বেও কোনও অর্থবহ উপায়ে সামগ্রিক উপযোগ বাড়ায় না।

• যদি কোনও ওয়েব পৃষ্ঠা লোড হতে 20 সেকেন্ড সময় নেয় এবং আমরা এটিকে 1 এস-এ কমিয়ে দিই, এটি ওয়েবসাইটের ইউটিলিটি 0 থেকে নিকটবর্তী অনন্ততায় বাড়িয়ে তুলতে পারে। মূলত এমন কিছু যা ভেঙেছিল কারণ এটি খুব ধীর ছিল, এখন এটি দরকারী।

Comments

এটি উল্লেখ করা গুরুত্বপূর্ণ যে আপনার প্রোগ্রামটি চলাকালীন যদি আপনার সাজানো 1000 বার বলা হয়, 20 মিমি থেকে 1 এমএস পর্যন্ত অনুকূলকরণ করা একটি বড় ব্যাপার।

— গরুর মাংসের মাংস

Answer 13

কোন ধরণের অপ্টিমাইজেশন অকাল নয়?

আপনার অ্যাপ্লিকেশনটির সাথে পরিচিত পারফরম্যান্সের সমস্যাটি স্থির করে এমন একটি অপ্টিমাইজেশন বা এমন একটি অপ্টিমাইজেশন যা আপনার অ্যাপ্লিকেশনটিকে সঠিকভাবে সংজ্ঞায়িত গ্রহণযোগ্যতার মানদণ্ড পূরণ করতে দেয়।

চিহ্নিত হওয়ার পরে, কিছুক্ষণ ঠিক করার জন্য নেওয়া উচিত এবং পারফরম্যান্স সুবিধাটি পরিমাপ করা উচিত।

(যেমন এটি নয় - "আমি মনে করি কোডের এই বিটটি মনে হচ্ছে এটি ধীর হতে পারে, আমি এর পরিবর্তে Y ব্যবহার করতে এক্স পরিবর্তন করব এবং এটি আরও দ্রুত হবে")।

আমি প্রচুর অকাল "অপ্টিমাইজেশান" এর মুখোমুখি হয়েছি যা শেষ পর্যন্ত কোডটিকে ধীর করে দিয়েছে - এই উদাহরণে আমি 'অজান্তেই ভাবি না' বোঝাতে অকালকাল নিচ্ছি। পারফরম্যান্সটি অপ্টিমাইজেশনের পূর্বে এবং পরে এবং কেবল কোডই কার্যকর রাখতে পারে যা কার্য সম্পাদনকে উন্নত করে bench

Answer 14

"অকালীন অপটিমাইজেশন হ'ল সমস্ত অশুভের মূল" আমাদের মধ্যে প্রায় সকলেই শুনে / শুনেছেন

সত্য। দুর্ভাগ্যক্রমে এটি সর্বকালের সর্বাধিক (দূষিতভাবে) অপব্যবহৃত প্রোগ্রামিং কোটগুলির মধ্যে একটি। যেহেতু ডোনাল্ড নুথ মেমটি তৈরি করেছেন তা উদ্ধৃতি থেকে কিছু মূল প্রসঙ্গ যুক্ত করার মতো:

আমাদের ছোট কার্যকারিতা সম্পর্কে ভুলে যাওয়া উচিত, সময়ের প্রায় 97% বলুন: অকাল অনুকূলতা হ'ল সমস্ত মন্দের মূল। তবুও আমাদের সেই সমালোচনামূলক 3% তে আমাদের সুযোগগুলি অতিক্রম করা উচিত নয়। ... একটি ভাল প্রোগ্রামার ... সমালোচনামূলক কোডটি মনোযোগ সহকারে দেখার জন্য বুদ্ধিমান হবে; তবে কেবলমাত্র সেই কোডটি সনাক্ত করার পরে। ... পরিমাপ সরঞ্জামগুলি ব্যবহার করে এমন প্রোগ্রামারদের সর্বজনীন অভিজ্ঞতাটি হ'ল তাদের স্বজ্ঞাত অনুমানগুলি ব্যর্থ হয়

দ্রষ্টব্য যে নুথ রানটাইমে কার্যকর করার গতি সম্পর্কে বিশেষভাবে কথা বলেছেন ।

.. প্রোগ্রামাররা তাদের কর্মসূচির অরাগঠনিক অংশগুলির গতি সম্পর্কে চিন্তাভাবনা করে, বা উদ্বিগ্ন হয় time

এছাড়াও, তিনি নিবন্ধটি লিখেছিলেন ১৯ 197৪ সালে যখন কোনও মেশিন রিসোর্স যেখানে প্রিমিয়াম এবং কার্য সম্পাদনের গতি এবং প্রোগ্রামের রক্ষণাবেক্ষণের মধ্যে নেতিবাচক সম্পর্ক (উচ্চ গতি - কম রক্ষণাবেক্ষণযোগ্য) সম্ভবত এখনকার চেয়ে বেশি শক্তিশালী ছিল।

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

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

• খালি চোখে দৃশ্যমান এবং বাধা (O) (1) বিকল্প উপস্থিত রয়েছে যেখানে বৃহত্তর এন সঙ্গে ডাটাবেসে রাউন্ডট্রিপ সংখ্যার যেমন O (1) হিসাবে পরিচয় করানোর আগে এড়ানো যেতে পারে

এমনকি রানটাইম কার্যকর করার গতির সাথেও সম্পর্কিত নয়:

• চিন্তাশীল অগ্রিম নকশা

• স্ট্যাটিক টাইপিং (!)

• ইত্যাদি / মানসিক প্রচেষ্টা যে কোন ফর্ম