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

Question

আমি সম্প্রতি স্ট্যাক ওভারফ্লো উপর একটি প্রশ্ন জিজ্ঞাসা খুঁজে বের করতে কেন isset () যাও strlen () তুলনায় দ্রুততর ছিল মধ্যে পিএইচপি । এটি পাঠযোগ্য কোডের গুরুত্ব এবং কোডে মাইক্রো-সেকেন্ডের কর্মক্ষমতা উন্নতি বিবেচনা করার মতো কিনা তা নিয়ে প্রশ্ন উত্থাপন করেছে।

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

আমি এতটা নিশ্চিত নই - সম্ভবত কম্পিউটিং পাওয়ার বৃদ্ধির অর্থ আমাদের আর এই ধরণের মাইক্রো পারফরম্যান্স উন্নতি বিবেচনা করতে হবে না? সম্ভবত এই ধরণের বিবেচনাটি প্রকৃত ভাষার কোডটি লেখার লোকদের উপর নির্ভর করে? (উপরের ক্ষেত্রে পিএইচপি এর)।

পরিবেশগত কারণগুলি গুরুত্বপূর্ণ হতে পারে - ইন্টারনেট বিশ্বের 10% শক্তি ব্যবহার করে। আমি অবাক হই যে কয়েক মিলিয়ন ওয়েবসাইটগুলিতে ট্রিলিয়ন কোটি বার প্রতিলিপি করা হলে কয়েক মাইক্রো সেকেন্ডের কোডটি কীভাবে অপচয় হয়?

আমি প্রোগ্রামিং সম্পর্কিত তথ্যের উপর ভিত্তি করে উত্তরগুলি জানতে চাই।

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

আমার 25 টি উত্তরগুলির ব্যক্তিগত সারসংক্ষেপ, সকলকে ধন্যবাদ।

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

if (expensiveFunction() || counter < X)

হতে হবে

if (counter < X || expensiveFunction())

( @ জিদারস্ক 8 এর উদাহরণ ) এটি একটি সস্তা ব্যয় হতে পারে এবং তাই কোড পরিবর্তন করা হবে মাইক্রো-অপ্টিমাইজেশন। তবে, একটি মৌলিক বোঝার সাথে আপনার দরকার হবে না, কারণ আপনি এটি প্রথমে সঠিকভাবে লিখবেন।

Comments

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

— মার্টিন ইয়র্ক

মূল শব্দটি বিবেচনা করা হলে তিনি ভুল নন। এটি সম্পর্কে আপনার কিছু ধারণা থাকা দরকার।

— জেফো

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

— তামারা উইজসম্যান

আপনি কি "বিশ্বের 10% শক্তি" উত্স সরবরাহ করতে পারেন?

— মাইকেল ইস্টার

coder does not consider performance in their code even at the micro level, they are not good programmersমাইক্রো-অপ্টিমাইজিং থেকে খুব আলাদা। এটা ঠিক ভাল কোডিং।

— ওলিভিরাজর

Answer 1

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

মাইক্রো-অপ্টিমাইজেশনের সমস্যাটি হ'ল প্রোগ্রামগুলি কীভাবে প্রয়োজনের চেয়ে বেশি সময় ব্যয় করে সে সম্পর্কে কোনও ধারণা ছাড়াই এটি সাধারণত করা হয়।

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

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

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

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

Answer 2

সংখ্যাগুলি যদি এটি বলে তবেই মাইক্রো-অপ্টিমাইজেশন গুরুত্বপূর্ণ ization

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

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

Comments

অন্যদিকে, ধীর বনাম দ্রুততর ফাংশন ব্যবহারের মধ্যে যদি কোনও সমস্যা হয় তবে ধীর ফাংশনটি ব্যবহার করার কোনও কারণ নেই - যেমন আইসেটের ক্ষেত্রে এখানে।

— মাভ্রিক

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

— টমাসের মালিক

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

— মাভ্রিক

+1 অত্যন্ত অনুকূলিত কোড কম পাঠযোগ্য এবং রক্ষণাবেক্ষণযোগ্য ... তবে সবসময় হয় না ...

— বোজ

আরও বেশি ক্ষেত্রে যেখানে পারফরম্যান্স গুরুত্বপূর্ণ: (1) গেমিং; (২) বিপুল পরিমাণে ডেটা; (3) উচ্চ ট্র্যাফিক ওয়েব সাইট; (৪) অত্যন্ত জটিল ইউআইয়ের প্রতিক্রিয়া; (5) পরিষেবাটি যা ভাইরাস যাচাইয়ের মতো পটভূমিতে চলবে; ()) অর্থ; (7) স্মার্টফোন; ইত্যাদি। এটি আরটিএস এবং এমবেডেড সিস্টেমের মতো রহস্যজনক ক্ষেত্রে সীমাবদ্ধ নয়।

— রেক্স কের

Answer 3

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

প্রোগ্রাম অপ্টিমাইজেশনের প্রথম বিধি: এটি করবেন না।

প্রোগ্রাম অপ্টিমাইজেশনের দ্বিতীয় বিধি (কেবল বিশেষজ্ঞদের জন্য!): এটি এখনও করবেন না ।

^{উইকিপিডিয়া থেকে উদ্ধৃতি ব্রিটিশ ইংরেজি জন্য সংশোধন করা হয়েছে। * 8 ')}

দ্বিতীয় নিয়মে অন্তর্ভুক্তটি হ'ল আপনার কোডটি প্রোফাইল করা এবং কেবলমাত্র কোনও জিনিসকে অনুকূলকরণের জন্য সময় ব্যয় করা যা কোনও পার্থক্য তৈরি করবে।

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

এমনকি সিতেও আপনাকে সংকলকটির চেয়ে কোডের কোনও বিভাগকে কীভাবে অপ্টিমাইজ করা যায় সে সম্পর্কে আরও জানতে অপ্টিমাইজেশনে বেশ ভাল থাকতে হবে।

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

isset()পিএইচপিstrlen() মধ্যে বনাম

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

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

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

ব্যক্তিগত অভিজ্ঞতা থেকে একটি উদাহরণ

এই জাতীয় বিরোধী-অপ্টিমাইজেশনের উদাহরণ হিসাবে , আমাকে একবার ফর্মের কোডভর্তি একটি বিশাল কোডবেস স্যানিটাইজ if x==0 z=0 else z=x*yকরতে হয়েছিল কারণ কেউ ধারণা করেছিলেন যে কোনও ভাসমান পয়েন্টের গুণটি সবসময় একটি শাখার চেয়ে বেশি ব্যয়বহুল হয়ে উঠবে। মূল টার্গেট আর্কিটেকচারে এই অপ্টিমাইজেশানটি কোডটিকে বিশালতার অর্ডারে দ্রুত চালিত করে, তবে সময় পরিবর্তন হয়।

যখন আমরা এই কোডটি আরও আধুনিক সিপিইউতে ব্যবহার করার চেষ্টা করলাম যা উচ্চতর পাইপলাইন করা হয়েছিল পারফরম্যান্সটি ভয়াবহভাবে খারাপ ছিল - এই বিবৃতিগুলির প্রত্যেকটিই পাইপলাইন ফ্লাশের কারণ হয়। কোডটি এই সমস্ত লাইনকে সরলকরণের z=x*yজন্য প্রোগ্রামটিকে নতুন আর্কিটেকচারে দ্রুততর আকারের একটি অর্ডারকে দ্রুত চালিত করে, অ্যান্টি-অপ্টিমাইজেশনের দ্বারা হারানো পারফরম্যান্স পুনরুদ্ধার করে ।

আমাদের সাধারণত আজ যে সমস্যাগুলির জন্য অনুকূলিতকরণ করতে হবে সেগুলি 20 বা 10 বছর আগে আমাদের অনুকূলিতকরণের তুলনায় খুব আলাদা।

তারপর আমরা ঘড়ি চক্র প্রতি সবচেয়ে কাজ করছেন সম্পর্কে চিন্তিত, এখন আমরা আরো পাইপলাইন flushes, শাখা mispredictions ও CPU পর্যায়ে ক্যাশে মিস কিন্তু কেশ এবং interprocess যোগাযোগ সম্পর্কে উদ্বেজক হওয়ার সম্ভাবনাই বেশি হয়ে উঠছে অনেক বেশি গুরুত্বপূর্ণ হিসাবে আমরা মাল্টি- সরাতে প্রক্রিয়া এবং মাল্টি প্রসেসর আর্কিটেকচার। ড্রেপারের কাগজ এই বিষয়গুলির অনেকগুলি বোঝার জন্য সত্যই সহায়তা করতে পারে।

Comments

পাইপলাইন ফ্লাশ এবং ক্যাশে মিস হ'ল আপনি এড়াতে চান: ডি তাদের ভয়ঙ্কর ব্যয় করে। তবে কেবল কোডের কিছু অংশে যা তাদেরকে অনেক অনেক বহুবার উত্সাহিত করে।

— ডেডালনিক্স

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

— বেকুজ

সময় নষ্ট - এবং মাইকেল জ্যাকসন একজন প্রোগ্রামার ছিলেন তা প্রকাশ করে যে মাইক্রো-অপ্টিমাইজেশনের প্রকৃত উদাহরণ দেওয়ার জন্য +1।

— বোজ

উদাহরণস্বরূপ +1। এটি সংকলকটিতে তুচ্ছ ট্রান্সফর্মেশনগুলি কেন ছেড়ে দেওয়া উচিত তা পুরোপুরি ব্যাখ্যা করে।

— back2dos

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

— ডেডালনিক্স

Answer 4

1. কোড লিখুন, এটি পরিষ্কার, সংক্ষিপ্ত, সহজ এবং স্ব-ব্যাখ্যামূলক।
2. বাধাগুলি সনাক্ত করতে পারফরম্যান্স পরীক্ষা করুন।
3. সমালোচনা বিভাগগুলি অপ্টিমাইজ করুন।

থাম্বের নিয়ম হিসাবে: আপনার কোডের 95% সময় 5% চালিত হয়। আপনি নিজের কোডটি প্রোফাইল / বেঞ্চমার্ক করার আগে in 95% সময় চালাচ্ছেন এমন 5% কোনটি দেখুন তার আগে অনুকূলকরণের কোনও অর্থ নেই।

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

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

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

Comments

আমার কাছে সর্বোত্তম উত্তরটি খুঁজে পাওয়া গেল, লক্ষণীয়ভাবে, বাগজিলা বিকাশকারীদের গাইডে: "আপনি যদি পঠনযোগ্য হওয়ার পরিবর্তে চতুর হওয়ার চেষ্টা করছেন, তবে সম্ভবত আপনি জিনিসগুলি" দ্রুত? "করার চেষ্টা করছেন যদি তাই হয় তবে কেবল মনে রাখবেন : কোনও সমস্যা বিদ্যমান থাকার আগে আপনি এটি সমাধান করার আগে সমাধান করবেন না If যদি আপনার কোডটি ধীরে ধীরে ধীরে ধীরে হয় (প্রকৃত, বিস্তারিত পরীক্ষাগুলি দ্বারা) আপনি যদি না জানেন তবে এটি "দ্রুত" তৈরি করার বিষয়ে চিন্তা করবেন না এটি কেবল সীমাবদ্ধ নয় অপ্টিমাইজেশন - অনেক প্রোগ্রামার ক্রমাগত সমস্যাগুলি সমাধান করে যা এখন পর্যন্ত কেউ অনুভব করেনি that এটি করবেন না "" bugzilla.org/docs/developer.html#general

— মার্কো

আমি সাধারণত সম্মত হই - এক লাইন বাদে, আমি যুক্তি দিই যে "প্রত্যেক বুদ্ধিমান তারা মনে করে যে তারা মাইক্রো-অপ্টিমাইজ করতে পারে" ...;)

— নিম

@ নিম: পয়েন্ট তোলা;)

— back2dos

Answer 5

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

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

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

আরেকটি বাস্তবতা হ'ল লোকেরা কোডটি পুনরায় ব্যবহার করতে পছন্দ করে এবং এটি শেষ হওয়ার পরে আপনি এটি লেখার চেয়ে আলাদা হতে পারে। হঠাৎ লোকেরা যত্ন নিতে পারে।

উদাহরণস্বরূপ, বলুন আপনি কোনও পিসিতে অ্যাংরি পাখির মতো কিছু লিখেছিলেন বা গেম কনসোলের জন্য। আপনি আপনার পদার্থবিজ্ঞান সিস্টেম এবং আপনার গ্রাফিক্স সিস্টেমে অপ্টিমাইজেশন উপেক্ষা করেছেন - কারণ আজকাল 2.5 গিগাহার্টজ দ্বৈত কোরটি ন্যূনতম এবং আপনার গেমটি যথেষ্ট ভাল কাজ করে। তারপরে স্মার্ট ফোনগুলি আসে এবং আপনি এটি পোর্ট করতে চান। ওহ ডার্ন, একটি 600 মেগাহার্টজ এআরএম কোর?

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

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

এই সাইটগুলিতে এটি কোনও জনপ্রিয় মতামত নয়। বাই বাই খ্যাতি পয়েন্টগুলি ....

Comments

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

— ডাঃ জিম্বব

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

— কালেব

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

— phkahler

Answer 6

প্রথমে আপনার কেস নেওয়া যাক: পিএইচপি

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

সাধারণভাবে,

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

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

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

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

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

Answer 7

মাইক্রো অপ্টিমাইজেশন হ'ল এমন অনেক উত্তর রয়েছে বলে মনে হচ্ছে

ট্রেডঅফস সম্পর্কে সমস্ত - কর্মক্ষমতা, সময়, ব্যয়, প্রচেষ্টা, পঠনযোগ্যতা / রক্ষণাবেক্ষণযোগ্যতা এবং আরও অনেক কিছু।

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

if (counter < X && shouldDoThis()) // shouldDoThis() is an expensive function

সর্বদা তুলনায় ভাল

if (shouldDoThis() && counter < X ) 

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

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

Comments

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

— tscuzzy

এটি অত্যন্ত বিপজ্জনক উদাহরণ। একটি অপ্টিমাইজেশনের আচরণ পরিবর্তন করা উচিত নয় । এমনকি এটির প্রস্তাবনাও একটি অপ্টিমাইজেশন যা লোকেদের অন্ধভাবে একে অপরের সাথে পরিবর্তিত করার জন্য উল্লেখযোগ্য শব্দার্থ পরিবর্তনের জন্য বিবেচনা না করে (যেখানে ভাষাগুলিতে সংক্ষিপ্ত-সার্কিট অপারেটর) regard cheap() && expensive()expensive () && cheap()&&

— মার্ক বুথ

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

— phkahler

@ মার্কবুথ আমাকে এখানে ফিকাহলারের সাথে একমত হতে হবে, এই ফাংশনগুলির কোনওটিরই পার্শ্ব প্রতিক্রিয়া হওয়া উচিত নয়! একটি বিবৃতিতে কনডিয়োনোর ক্রম অবশ্যই প্রোগ্রামের ফলাফলের উপর প্রভাব ফেলবে না। আমার উদাহরণটি if (x<100 && isPrime(x))আরও স্পষ্ট করার জন্য আরও ভাল হিসাবে এটি লেখা হবে।

— zidarsk8

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

— মার্ক বুথ

Answer 8

আমার কেরিয়ারের শুরুর দিকে কম্বল স্টেটমেন্ট যেমন "মাইক্রো-অপ্টিমাইজ করবেন না" প্রচুর বিভ্রান্তির সৃষ্টি করেছিল। সবকিছু পরিস্থিতিগত; সুতরাং, লোকেরা "এটি করুন" না করে "সেরা অনুশীলন" বলার কারণ।

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

• এসকিউএল সার্ভারের একটি নতুন সংস্করণ যার অর্থ কয়েক হাজার টাকা কেনার ধারণা সম্পর্কে আমার বসকে বিক্রি করা।
• নতুন প্রযুক্তি শেখার ধারণাটিতে বিকাশকারীদের বিক্রি করা।

আমি অভিজ্ঞতা থেকে জানি যে এটি ঘটবে না। সুতরাং, আমি ছাড়তে পারলাম, চাপের শেষ নেই বা সেরা অনুশীলনটি অনুসরণ করব না।

সিদ্ধান্তের পিছনে রাজনৈতিক, প্রযুক্তিগত এবং আর্থিক বিবেচনা রয়েছে যা সামগ্রিক ফলাফলকে প্রভাবিত করে। সিদ্ধান্ত নেওয়ার সময় এই ঘটনাটি মনে রাখুন এবং আপনার যুদ্ধগুলি বুদ্ধিমানের সাথে চয়ন করুন।

" প্রত্যেক কিছুর জন্য একটি seasonতু আছে, আকাশের নীচে প্রতিটি ক্রিয়াকলাপের জন্য সময় " "

Comments

বিটিডাব্লু, আপনি ইনলাইন এসকিউএল-এর একটি মাইক্রো-ওআরএম বিকল্প হিসাবে ড্যাপারটি ব্যবহার করতে পারেন ।

— ড্যান

LINQ and Entity Framework should be used in lieu of inline SQL- কিছু অপ্টিমাইজ করার জন্য আপনার আসলে ইনলাইন এসকিউএল প্রয়োজন না হওয়া পর্যন্ত; EF যে এসকিউএল উত্পাদন করে তা সর্বদা অনুকূল হয় না।

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

হ্যাঁ, যদি আপনার বস এসকিউএল 2 কে 8 এর লাইসেন্স ব্যয়ের বিষয়ে উদ্বিগ্ন হন (বা অন্য যে কোনও কিছু বর্তমান হতে পারে), আপনার উল্লেখ করা উচিত যে খুব শীঘ্রই ইওএল ভারতে আসার যথেষ্ট পুরানো (যদি এটি ইতিমধ্যে না থাকে)

— ওয়ারেন

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

— পি.ব্রেইন.ম্যাকি

ঠিক তাই আপনি জানেন, আপনি এসকিউএল 2000 সহ ইএফ ব্যবহার করতে পারেন The ডিজাইনারটি কাজ করে না, তবে আসল সত্তা কাঠামোটি এসকিউএল 2000 সমর্থন করে the SQL 2000 ডাটাবেস হিসাবে, সমস্ত ক্লাস তৈরি করতে ডিজাইনারটিকে নির্দেশ করুন, তারপরে .edmx ফাইলে যান এবং লক্ষ্য ডাটাবেস সংস্করণটি 2000 এ পরিবর্তন করুন এবং আপনার এসকিএল সার্ভার 2000 ডাটাবেসে সংযোগের স্ট্রিংটি নির্দেশ করুন। সেরা সমাধান নয়, তবে আপনি আপগ্রেড করতে না পারলে এটি কাজ করে।

— নীল

Answer 9

এটি সর্বদা একটি বাণিজ্য।

প্রথমত, কম্পিউটার শিল্পটি প্রায় অর্থ সম্পর্কে money বিকাশকারী হিসাবে আপনার যা করা দরকার তা হ'ল গ্রাহকের জন্য মান উত্পন্ন হয় যাতে আপনি অর্থ পান (এটি একটি ওভারসিম্প্লিফিকেশন তবে মূল বিষয়টি এখানে)

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

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

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

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

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

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

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

Comments

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

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

মাইক্রো-অপ্টিমাইজেশন +1 রক্ষণাবেক্ষণ এবং বিবর্তন আরও মূল্যবান। যদিও আমি নিশ্চিত যে কম্পিউটার শিল্পটি কেবল অর্থের চেয়ে বেশি? উদাহরণস্বরূপ, ওপেন সোর্স, শিক্ষা, উদ্ভাবন, পরিচালনা, সম্প্রদায় ইত্যাদি I'm

— বোজ

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

— ডেডালনিক্স

Answer 10

পারফরম্যান্স একটি বৈশিষ্ট্য

জেফ অ্যাটউডের নিবন্ধটি একটি উচ্চ পারফরম্যান্স ওয়েবসাইট তৈরির জন্য দুর্দান্ত এবং এটি করার গুরুত্ব ...

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

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

Answer 11

বিকাশকারী সময়ের জন্য কম্পিউটার সময়ের চেয়ে বেশি খরচ হয়। এটিই আপনি সাধারণত অনুকূল করতে চান। কিন্তু:

• মাইক্রো-অপটিমাইজেশন এবং অ্যালগরিদমিক জটিলতার মধ্যে পার্থক্য রয়েছে। আপনি সঠিক অ্যালগরিদম ব্যবহার করছেন তা নিশ্চিত হওয়ার জন্য যথেষ্ট সময় ব্যয় করুন ।
• নিশ্চিত করুন যে আপনি সঠিক প্রশ্ন জিজ্ঞাসা করছেন, select (select count(*) from foo) >= 1একই জিনিস নয় select exists(select 1 from foo)।
• কিছু ভাষার আইডিয়ামগুলি কেবলমাত্র দ্রুত কারণ এটি জনপ্রিয়, সেগুলি ব্যবহার করা ঠিক আছে, কারণ ভাষার বেশিরভাগ সাবলীল ব্যবহারকারী তাদের সাথে পরিচিত হবেন। (আপনার উদাহরণ একটি ভাল উদাহরণ)।

Answer 12

আপনি কী অনুকূলিত করতে চান?

• সফটওয়্যার পারফরম্যান্স?
• নির্ভরযোগ্যতা?
• প্রোগ্রামার উত্পাদনশীলতা?
• গ্রাহক সন্তুষ্টি?
• শক্তি দক্ষতা?
• Maintainability?
• বাজার করার সময়?
• কত টাকা লাগে?

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

আপনি যদি ক্রমাগত ব্যবহারকারীর ইনপুটটির দৈর্ঘ্যের এবং যে পরিমাণ দুটি নিয়মিত সময় নির্ধারণ করতে যে দুটি দৈর্ঘ্য ক্রমাগত কী-স্ট্রোকের মধ্যবর্তী সময়ের চেয়ে অনেক ছোট তা আপডেট করার প্রয়োজন হয় তবে এটি কোন নিয়মিত নয় তা সত্যিকার অর্থেই কিছু যায় আসে না তুমি ব্যাবহার কর. অন্যদিকে, যদি আপনাকে এক বিলিয়ন স্ট্রিংয়ের দৈর্ঘ্য নির্ধারণ করতে হয়, আপনি সম্ভবত বিভিন্ন রুটিনের মধ্যে পারফরম্যান্সের পার্থক্যের দিকে খুব মনোযোগ দিতে চান। প্রথম ক্ষেত্রে, আপনি এমন কোড লিখতে পছন্দ করতে পারেন যা বোঝা এবং যাচাই করা সহজ; দ্বিতীয় ক্ষেত্রে, আপনি গতির জন্য পাঠযোগ্যতার বাণিজ্য করতে ইচ্ছুক হতে পারেন।

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

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

Comments

+1 গত কয়েক বছরে মোবাইল ডিভাইসগুলি আবার কোড অপ্টিমাইজেশানের উপর অত্যন্ত নির্ভরশীল হয়ে উঠেছে তা উল্লেখ করার দরকার নেই। যে কেউ অপ্টিমাইজড কোডটি লেখেন না বা কমপক্ষে বিবেচনা করুন এটি মোবাইল ডিভাইসে সহজেই চালানোর জন্য তাদের সিপিইউ নিবিড় অ্যাপ্লিকেশন পেতে অসুবিধা হতে পারে।

— স্টাইলার

আপনার সম্ভাব্য অপটিমেশনের তালিকার মতো +1 করুন তিনি সমাবেশ / দুর্গ ব্যবহার করেছেন

— বোজ

@ স্টাইলার: মোবাইল ডিভাইসগুলিতে জিবিএস মেমরির কোয়াড কোর সিপিইউ না আসা পর্যন্ত এটি বেশিদিন কাটে না, ইতিমধ্যে আমাদের কাছে ডুয়াল কোর স্মার্টফোন রয়েছে।

— মিথ্যা রায়ান

@ মিথ্যা রায়ান: হ্যাঁ এটি সত্য, তবে বেশিরভাগ অগ্রগামীদের মতো তাদেরও কাঠের নৌকায় ভ্রমণ করতে হয়েছিল;)

— স্টাইলার

Answer 13

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

তবুও , প্রোগ্রামারকে কোড লেখার সময় অবশ্যই বোকামি কাজগুলি এড়াতে চেষ্টা করা উচিত ।

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

এই জিনিসগুলি অভিজ্ঞ প্রোগ্রামারকে মনে রাখা সহজ এবং প্রায় সর্বদা কোডের মান উন্নত করে।

Comments

বুঝতে পেরেছি যে আমার প্রশ্ন সম্পাদনাতে আমার আরও পরিষ্কার হওয়া দরকার, আমি সত্যিই একই কথা বলছিলাম - আমি এটি আপডেট করেছি।

— বোজ

Answer 14

কীটি অপ্টিমাইজ করবেন তা সিদ্ধান্ত নেওয়ার সময় সর্বদা আমদাহলের আইন মনে রাখবেন । সুনির্দিষ্ট গণিতের জন্য লিঙ্কটি দেখুন; স্মরণ রাখার মতো অদ্ভুত বিবৃতিটি হ'ল:

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

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

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

Comments

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

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

শয়তান সেখানে "গড়" শব্দটিতে রয়েছে। এটি গাণিতিক ক্ষেত্রে যে কোনও প্রোগ্রামের গতি বাড়ানোর জন্য প্রতিটি টুকরো গড়ে গড়ে 50% বাড়িয়ে নেওয়া উচিত । এখন, যদি আপনি প্রোগ্রামটিকে এমন একটি কাজের মধ্যে ভাগ করতে পারেন যা time৫% রানটাইম এবং অন্যটি ২৫% নেয় এবং পূর্বের 3x দ্রুততর করে তোলে, তবে শেষের কাজটিতে কিছু না করেও আপনাকে সামগ্রিকভাবে ৫০% দেবে। তবে আরও সাধারণ ক্ষেত্রে হ'ল এমন কয়েক ডজন "কাজ" রয়েছে যা প্রত্যেকে রানটাইমের 5% এরও কম সময় নেয় - এবং তারপরে আপনাকে গতি বাড়াতে হবে বা তাদের অনেকগুলি থেকে মুক্তি দিতে হবে।

— zwol

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

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

Answer 15

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

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

আপনি যদি স্লো কোড সম্পর্কে প্রকৃতপক্ষে ব্যবহারকারীদের কাছ থেকে অভিযোগ পেয়ে থাকেন তবে সেগুলি বিবেচনার জন্য উপযুক্ত তবে কেবল যদি সমস্ত কিছু সমাধান করা হয়ে থাকে, যথা:

• কোডটি কি ভাল লেখা আছে?
• অ্যাপ্লিকেশনটি কোনও সমস্যা ছাড়াই এর ডেটা অ্যাক্সেস করতে সক্ষম?
• একটি ভাল অ্যালগরিদম ব্যবহার করা যেতে পারে?

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

Answer 16

এক্সিকিউশন গতি এমন অনেকগুলি কারণ যা একটি প্রোগ্রামের মানকে অবদান রাখে। প্রায়শই সময়, গতির পাঠযোগ্যতা / রক্ষণাবেক্ষণের সাথে একটি বিপরীত সম্পর্ক থাকে। প্রায় সব ক্ষেত্রেই কোড অবশ্যই মানব পাঠযোগ্য হতে হবে যাতে কোডটি বজায় রাখা যায়। কেবলমাত্র পাঠযোগ্যতার সাথে আপোস করা যেতে পারে যখন গতি একটি প্রয়োজনীয় প্রয়োজন। পূর্ণ পঠনযোগ্যতা / রক্ষণাবেক্ষণের অনুমতি দেওয়ার চেয়ে কোড দ্রুত করার প্রয়োজনীয়তা খুব কমই প্রয়োগযোগ্য, তবে এমন কিছু ক্ষেত্রে রয়েছে যেখানে এটি হবে। মনে রাখার মূল বিষয় হ'ল মাইক্রো অপ্টিমাইজড কোডটি প্রায়শই হ্যাকি কোড হয়, সুতরাং কোথাও কোনও সংজ্ঞায়িত প্রয়োজনীয়তা না থাকলে সমস্যাটি সমাধানের প্রায়শই এটি ভুল উপায়। উদাহরণস্বরূপ, ব্যবহারকারী সিআরইউডি অপারেশনে .5 সেকেন্ড এবং 1 সেকেন্ডের এক্সিকিউশন বারের মধ্যে পার্থক্যটি প্রায় দেখবে না, সুতরাং .5 সেকেন্ডে পৌঁছানোর জন্য আপনাকে কোনও অ্যাসেম্বলি-ইন্টারপ-হ্যাকফেস্টে যেতে হবে না। হ্যাঁ, আমি কাজ করতে একটি হেলিকপ্টারটি উড়াতে পারতাম এবং এটি 10 ​​গুণ দ্রুত গতিতে হবে তবে দাম এবং এই কারণে যে হেলিকপ্টারটি আরো অনেক বেশি কঠিন।আপনি যখন অযথা কোডকে মাইক্রো-অপ্টিমাইজ করেন, তখন আপনি যা করছেন ঠিক তা হ'ল: অহেতুক জটিলতা এবং অতিরিক্ত অতিরিক্ত লক্ষ্যে পৌঁছানোর জন্য ব্যয় যোগ করা।

Answer 17

মাইক্রো-অপ্টিমাইজেশন গুরুত্বপূর্ণ যখন আপনি একটি প্রতিবন্ধকতা আঘাত। আপনি যে জিনিসটির যত্ন নেবেন সেটি মেমরি হতে পারে, থ্রুপুট হতে পারে, বিলম্ব হতে পারে বা বিদ্যুৎ খরচ হতে পারে। নোট করুন যে এগুলি সিস্টেম-স্তরের বৈশিষ্ট্য; আপনার প্রতিটি উপায়ে প্রতিটি উপায়ে অপ্টিমাইজ করার দরকার নেই (এবং করতে পারবেন না)।

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

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

তবে, আপনি ন্যানোসেকেন্ড, মিলিসেকেন্ড, সেকেন্ড বা ঘন্টা নিয়ে কাজ করছেন কিনা তা বিবেচ্য নয়; বিষয়গুলি একই। সিস্টেমের প্রসঙ্গে এবং আপনি কী অর্জন করতে চাইছেন সেগুলি সম্পর্কে তাদের মূল্যায়ন করতে হবে।

এই সাম্প্রতিক প্রশ্ন আমি উত্তর থেকে একটি উদাহরণ স্ট্যাক ওভারফ্লো : একটি কেস যেখানে মাইক্রো-অপ্টিমাইজেশান প্রয়োজনীয় ছিল একটি এমবেডেড সিস্টেমের জন্য ওপেন সোর্স ভিডিও এনকোডার ।

Answer 18

মাইক্রো-অপ্টিমাইজেশানের বৃহত্তম সমস্যাটি হ'ল এটি আপনাকে রক্ষণাবেক্ষণের জন্য আরও কঠোর কোড লিখতে পরিচালিত করে।

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

অনেকগুলি মাইক্রো-অপ্টিমাইজেশান তৈরি করা আপনার পক্ষে এমন কোনও বিষয়ের বিরুদ্ধে লড়াই করতে প্রচুর সময় ব্যয় করবে যা সত্যিকার অর্থে গুরুত্বপূর্ণ নয়।

একটি ক্লিনার কোড তৈরি করা, বজায় রাখা সহজ, এবং আপনি যদি পারফরম্যান্সের সমস্যা পান তবে আপনার কোডটি আসলে কী ধীর করে দিচ্ছে তা নির্ধারণ করার জন্য আপনি একটি প্রোফাইল চালনা করার মাধ্যমে একটি আরও ভাল পদ্ধতির। এবং আসলে কী খারাপ তা সঠিকভাবে জেনে আপনি এটিকে ঠিক করতে পারেন।

আমি বলছি না যে মাইক্রো-অপ্টিমাইজেশান না করা বোকা কোড লেখার অজুহাত।

Answer 19

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

পরিবেশগত কারণগুলি এখানে প্রশ্নবিদ্ধ নয়, ser সার্ভারগুলি যাইহোক 24/7 চালিত হয় এবং যদি তারা প্রকৃতপক্ষে কোনও কিছু প্রক্রিয়া করে তবেই যদি এটি সত্যিই খুব দীর্ঘ সময় ধরে একটি কাজ চালিত হয় তবে তা গুরুত্বপূর্ণ।

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

Comments

+1 আলো বন্ধ করে দেওয়া বা প্রশ্নের উত্তর না দেওয়া।

— বোজ

Answer 20

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

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

Comments

আপনার ডেটা প্রায় কয়েকটি বিপথগামী উপাদানগুলির সাথে প্রায় বাছাই করা হয় যা চূড়ান্ত গন্তব্য থেকে খুব বেশি দূরে নয়, বাবলসার্ট আসলে কুইকোর্ট বা মার্জ্টের চেয়ে ভাল হতে পারে। অন্য সমস্ত কাজের জন্য, আপনার প্রোগ্রামিং ভাষা আপনাকে সরবরাহ করে এমন বিল্ট-ইন বাছাই করা ফাংশনটি ব্যবহার করা উচিত; এটি শুরু করার সহজতম উপায় (এবং বেশিরভাগ ভাষায় বিল্ট-ইন বাছাইয়ের ফাংশনটিতে ভাল পারফরম্যান্স থাকে)। খারাপ পরামর্শ:, start out with bad runtime characteristicইচ্ছাকৃতভাবে কোনও খারাপ রানটাইম বৈশিষ্ট্য দিয়ে শুরু করবেন না।

— মিথ্যা রায়ান

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

Answer 21

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

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

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

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

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

Comments

+1 উত্পাদন কোড যা কাজ করে তা সর্বদা প্রথম অগ্রাধিকার হওয়া উচিত।

— বোজ

@ কিথ, আসলে নূথ এটিকে প্রথমে বলেছিলেন এবং তিনি এর থেকে কিছুটা বেশি বলেছেন।

"এটি কাজ করুন, তারপরে এটি যত দ্রুত কাজ করা দরকার তত দ্রুত কাজ করুন", আনন।

— জন স্যান্ডার্স

আসলে ধর্ম হ'ল সমস্ত কুফলের মূল, তবে আমি খনন করি।

— থমাস এডিং

Answer 22

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

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

Answer 23

কোডটি কী করে সে সম্পর্কে একেবারে পরিষ্কার হওয়ার জন্য লিখতে হবে। তারপর, যদি এবং কেবল যদি এটা খুব ধীর হয়, ফিরে যান এবং এটা গতি বাড়াতে আপ করুন। কোডটি সর্বদা পরে দ্রুত হতে পারে, যদি এটি বোঝা যায় তবে- তবে ভাগ্যবান যদি এটি দ্রুত হয় তবে তা পরিষ্কার হয়ে যায় changing

Answer 24

এটি গুরুত্বপূর্ণ যদি:

1) কারও জীবন আপনার কোডের উপর নির্ভর করে। কারওর হার্ট রেট মনিটরে কার্যকর করতে 25 মিমি গ্রহণ করা একটি ফাংশন সম্ভবত একটি খারাপ ধারণা।

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

Comments

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

— জানম

Answer 25

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

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

এখানে আরও একটি প্রশ্ন বিবেচনা করতে হবে যা মেট্রিক দ্বারা পরিমাপকৃত পারফরম্যান্স: মৃত্যুদন্ড কার্যকরকরণের গতি, কার্যকরকরণে ব্যবহৃত স্মৃতি, নতুন বৈশিষ্ট্যগুলির বিকাশের গতি, সংকলিত বা ডি-সংকলিত ফর্মগুলিতে একটি সার্ভারে কোড বেসের আকার, স্কেলাবিলিটি, রক্ষণাবেক্ষণযোগ্যতা ইত্যাদি is ।? যদি পর্যাপ্তভাবে নেওয়া হয় তবে প্রশ্নটি তুচ্ছ হয়ে ওঠে, তবে আমি নিশ্চিত নই যে আপনি কতটা বিস্তৃতভাবে পারফরম্যান্স নিতে চেয়েছিলেন যা প্রায় কোনও কিছু হতে পারে যতক্ষণ না এটি কোনওভাবে পরিমাপ করা যায়।

---

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

Comments

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

— জোছিম সাউর

Answer 26

আমি মনে করি যে ভাল প্রোগ্রামিং এবং মাইক্রো-অপ্টিমাইজেশনের মধ্যে একটি বড় পার্থক্য রয়েছে।

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

এবং ভাল অ্যালগরিদম ইতিমধ্যে অনুকূলিত হয়। তারা দ্রুত হবে। তারা ছোট হবে। তারা সর্বনিম্ন প্রয়োজনীয় মেমরি ব্যবহার করবে।

এমনকি যদি তাদের আপনার প্রোগ্রামটি ব্যবহার করার ক্ষেত্রে এখনও সেই কর্মক্ষমতা না থাকে তবে এগুলি আপনি মাইক্রো-অনুকূলকরণ বিবেচনা করতে পারেন। এবং মাইক্রো-অপটিমাইজ করতে সক্ষম হতে আপনাকে ভাষাটি সত্যই জানতে হবে।

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

Answer 27

আইএমএইচও কোড-পঠনযোগ্যতা মাইক্রো-অপ্টিমাইজেশানের চেয়ে বেশি গুরুত্বপূর্ণ কারণ বেশিরভাগ ক্ষেত্রে মাইক্রো-অপ্টিমাইজেশনের পক্ষে এটির মূল্য হয় না।

জ্ঞানহীন অণু-অপ্টিমাইজেশান সম্পর্কিত নিবন্ধ :

আমাদের বেশিরভাগ হিসাবে, আমি ইকো দ্বারা মুদ্রণ প্রতিস্থাপন, ++ $ i দ্বারা $ i ++, বা একক উদ্ধৃতি দ্বারা ডাবল উদ্ধৃতি যেমন অজ্ঞান মাইক্রো-অপ্টিমাইজেশন সম্পর্কে ব্লগ পোস্ট পড়তে ক্লান্ত হয়ে পড়েছি। কেন? কারণ 99.999999% সময় এটি অপ্রাসঙ্গিক। কেন? সময়ের 99.99%, আপনি এপিসির মতো পিএইচপি এক্সিলারেটরটি আরও ভালভাবে ইনস্টল করতে চান, বা আপনার ডাটাবেস কলামগুলিতে এই অনুপস্থিত সূচিগুলি যুক্ত করতে বা হোমপেজে থাকা 1000 টি ডাটাবেস অনুরোধগুলি এড়াতে চেষ্টা করবেন।

মুদ্রণ আরও একটি ওপোড ব্যবহার করে কারণ এটি আসলে কিছু দেয়। আমরা সিদ্ধান্তে পৌঁছাতে পারি যে প্রতিধ্বনি প্রিন্টের চেয়ে দ্রুত is তবে একটি অপকোডের জন্য কিছুই হয় না, আসলে কিছুই হয় না।

আমি একটি নতুন ওয়ার্ডপ্রেস ইনস্টলেশন চেষ্টা করেছি। আমার ল্যাপটপে একটি "বাস ত্রুটি" শেষ হওয়ার আগে স্ক্রিপ্টটি থামবে, তবে ইতিমধ্যে অপকডের সংখ্যা ছিল ২.৩ মিলিয়নেরও বেশি। যথেষ্ট বলেছ.

সুতরাং বেশিরভাগ ক্ষেত্রে মাইক্রো অপটিমাইজেশন লক্ষ লক্ষ লোকের মধ্যে 1 টি অপারেশন সংরক্ষণ করে, তবে পঠনযোগ্যতা আরও খারাপ করে তোলে।

Answer 28

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

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

আমি এখানে অন্যদের দ্বারা তৈরি পয়েন্টগুলি ভাল এবং খারাপ উভয় অপটিমাইজেশনের নিষ্ক্রিয়তা হিসাবে পুনর্বার করব:

1. নির্দিষ্ট সমস্যার সাথে আপনার নির্ভরতা বদলে যেতে পারে এবং আপনার অ্যাপ্লিকেশনটির যৌক্তিক বিভাগটি শেষ করার আগে অনুকূলকরণে যে কোনও সময় ব্যয় করা সময় নষ্ট। আমি অপেক্ষাকৃত প্রাথমিক পর্যায়ে অনুকূলকরণের অর্থ। List<T>আপনার অ্যাপ্লিকেশন জাহাজগুলির মধ্যে আজ আপনার সময় এসেছে এবং আপনাকে এটি পরিবর্তন করতে হয়েছিল LinkedList<T>এবং এখন সমস্ত মানদণ্ডটি সময় এবং প্রচেষ্টার অপচয় ছিল waste

2. বেশিরভাগ ক্ষেত্রে আপনার অ্যাপ্লিকেশনটির আসল বিঘ্ন (আপনার পরিমাপযোগ্য পার্থক্য হিসাবে পড়ুন) আপনার কোডের 5% (বেশিরভাগ স্কয়ারের) হতে পারে এবং অন্যান্য 95% অনুকূলকরণ আপনার গ্রাহকদের কোনও সুবিধা দেয় না।

3. সাধারণত "টেকনিক্যালি" আরও ভাল পারফর্মিং কোড মানে আরও ভারবোসিটি যার পরিবর্তে আরও বেশি ত্রুটিযুক্ত প্রোন কোড হয় যার অর্থ কঠোর রক্ষণাবেক্ষণযোগ্যতা এবং আরও বেশি সময় ব্যয় হয় যার অর্থ আপনি কম অর্থ উপার্জন করেন means

4. 1% পারফরম্যান্স লাভের মাধ্যমে আপনি সারা বিশ্বের জন্য যে কার্বন পায়ের ছাপটি সংরক্ষণ করছেন তা গ্রীনহাউস গ্যাসগুলি দ্বারা সহজেই বামন হয়ে যায় আপনার দলটিকে সেই কোডটি ডিবাগিং এবং বজায় রাখতে হবে mit

বিশেষত খারাপ অপ্টিমাইজেশনের নেতিবাচকগুলি হ'ল :

1. এটি প্রায়শই আপনাকে প্রত্যাশা করে এমন পারফরম্যান্স দেয় না। সুতরাং, যেখানে এই প্রশ্ন দেখতে পাবেন অপ্টিমাইজেশন ভুল সর্বস্বান্ত আছে । আসলে এটা করতে বিরূপ প্রভাব আছে। অনাবন্ধিত আচরণের সাথে এটাই সমস্যা।

2. বেশিরভাগ আধুনিক সংকলকগণ যাইহোক এটি আপনার জন্য করবে।

আমি খারাপ এবং ভাল অপ্টিমাইজেশনের কয়েকটি উদাহরণ দেব:

খারাপ জন -

1. পরিবর্তে ছোট পূর্ণসংখ্যার প্রকারের ব্যবহার Int32।

2. ++i পরিবর্তে ব্যবহৃত i++

3. forপরিবর্তে foreach(সবচেয়ে খারাপ আমি দেখেছি, সম্পূর্ণ যুক্তি পরাজিত করে)

4. বন্ধ আউট ভেরিয়েবল এড়ানো

   string p;
   foreach (var item in collection)
       p = ...;
   

5. charস্ট্রিং কনটেন্টেশন চলাকালীন স্ট্রিংয়ের পরিবর্তে ব্যবহার করুন:

   string me = 'i' + "me myself"; // something along that line - causes boxing
   

ভাল (। নেট বিশ্ব থেকে। স্ব-ব্যাখ্যামূলক হওয়া উচিত) -

1. ডাবল লুক

   if (Dictionary<K, V>.TryGetValue(K, out V))
       do something with V
   

   পরিবর্তে

   if (Dictionary<K, V>.ContainsKey(K))
       do something with Dictionary<K, V>[K]
   

2. সব লোড করুন

   DirectoryInfo.EnumerateFiles();
   

   পরিবর্তে

   DirectoryInfo.GetFiles();
   

3. দুটি পর্যায়ে ingালাই:

   s = o as string;
   if (s != null)
       proceed
   

   পরিবর্তে

   if (o is string)
       s = (string)o;
   

4. অর্ডার যদি কিছু যায় আসে না

   if (counter < X || expensiveFunction())
   

   পরিবর্তে

   if (expensiveFunction() || counter < X)
   

5. বক্সিং

   void M<T>(T o) //avoids boxing
   {
   
   }
   

   পরিবর্তে

   void M(object o)
   {
   
   }
   

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

Answer 29

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

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

এদিকে কয়েক জন পেনি সঞ্চয় করা যখন আমার ঠিক পাশেই দু'জন লোক সস্তা হন এবং একজন কয়েক পেনি সস্তার জন্য ঠিক একই জিনিস সরবরাহ করেন এবং অন্যটি করেন না, এবং আমি আরও ব্যয়বহুল একটি বেছে নিই কারণ আমি তাদের টুপিটি পছন্দ করি বোকা মামলার মতো বলে মনে হয় হতাশার।

"মাইক্রো-অপ্টিমাইজেশান" বলা লোকেরা আমাকে প্রায়শই কৌতূহলীভাবে পরিমাপ, প্রসঙ্গ এবং ব্যবহারকারী-সমাপ্ত আলোচনা থেকে বঞ্চিত বলে মনে হয়, যখন প্রয়োগের জন্য তুচ্ছ না হয় তবে এই জাতীয় অনুকূলিতকরণ বিবেচনা করার জন্য তিনটিই থাকা উচিত। আমার কাছে একটি উপযুক্ত মাইক্রো-অপ্টিমাইজেশন মেমোরি লেআউট এবং অ্যাক্সেস প্যাটার্নগুলির মতো জিনিসের সাথে সম্পর্কিত, এবং যখন তারা ফোকাসে "মাইক্রো" বলে মনে হচ্ছে, তারা কার্যকরভাবে মাইক্রো নয়।

ভলিউমেট্রিক তাপ প্রসারণ ত্বকের জন্য অ্যালগরিদমিক জটিলতায় কোনও পরিবর্তন না করে আমি অ্যালগরিদমিক জটিলতায় কোনও পরিবর্তন না করে, অ্যালগরিদমিক জটিলতার কোনও পরিবর্তন না করেই, অ্যালগরিদমিক জটিলতায় কোনও পরিবর্তন না করে, আমি এত দীর্ঘ আগে না হয়ে, 24 সেকেন্ড থেকে 25 মিলি সেকেন্ডে (প্রায় 960 গুণ দ্রুত) কমিয়ে একটি অপারেশন পরিচালনা করেছিলাম managed "মাইক্রো-অপ্টিমাইজেশান" (যার মধ্যে সবচেয়ে বড়টি মেমোরি বিন্যাসে পরিবর্তন থেকে আসে যা এটি প্রায় ২ সেকেন্ডে নেমে আসে, তারপরে বাকী ছিল সিমডি এবং ভিটিউনে ক্যাশে মিস করার আরও বিশ্লেষণ এবং মেমরি বিন্যাসের আরও পুনর্বিন্যাস) things

ওল্ফায়ার এখানে কৌশলটি ব্যাখ্যা করেছেন এবং তিনি প্রয়োজনীয় সময়ের সাথে লড়াই করেছেন: http://blog.wolfire.com/2009/11/volumetric-heat-diffusion-skinning/

আমার প্রয়োগটি এক মিনিটেরও কম সময় নেওয়ার জন্য সংগ্রাম করতে গিয়ে মিলি সেকেন্ডে এটি করতে সক্ষম হয়েছিল:

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

পরিমাপ, ব্যবহারকারীর সমাপ্তির প্রয়োজনীয়তা, প্রসঙ্গ

আমি এখানে রবার্টের মন্তব্যটি সত্যিই পছন্দ করেছি এবং আমি যে বক্তব্যটি চেয়েছিলাম তা করতে ব্যর্থ হয়েছি:

ঠিক আছে, চলো। কেউ তর্ক করতে যাচ্ছেন না যে এই ধরণের পরিবর্তন "এর পক্ষে উপযুক্ত নয়"। আপনি একটি বাস্তব সুবিধা প্রদর্শন করতে সক্ষম হন; অনেক তথাকথিত মাইক্রো-অপ্টিমাইজেশন পারে না।

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

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

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

Comments

ঠিক আছে, চলো। কেউ তর্ক করতে যাচ্ছেন না যে এই ধরণের পরিবর্তন "এর পক্ষে উপযুক্ত নয়"। আপনি একটি বাস্তব সুবিধা প্রদর্শন করতে সক্ষম হন; অনেক তথাকথিত মাইক্রো-অপ্টিমাইজেশন পারে না।

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

@ রবার্টহারভে এটি এমন একটি বিষয় যা আমি প্রত্যাশা করেছিলাম, যেহেতু কিছু লোক "মাইক্রো-অপ্টিমাইজেশন" বলে অভিহিত করা অগত্যা অণুবীক্ষণিক নয়, তবে এটি প্রসঙ্গ, পরিমাপ ইত্যাদির উপর নির্ভরশীল issetবনাম strlenফোকাসে আরও ক্ষুদ্র বলে মনে হয় প্রসঙ্গ এবং পরিমাপ অনুপস্থিত। :-D

— ড্রাগন শক্তি

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

— ড্রাগন এনার্জি

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

— rwong

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

— rwong

Answer 30

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

Comments

এই পোস্টটি পড়ার চেয়ে শক্ত (পাঠ্যের প্রাচীর)। আপনি এটিকে আরও ভাল আকারে সম্পাদনা করতে আপত্তি করবেন ?

— gnat