সাধারণ বনাম কমপ্লেক্স (তবে কার্য সম্পাদন দক্ষ) সমাধান - কোনটি বেছে নেবে এবং কখন?

Question

আমি কয়েক বছর ধরে প্রোগ্রামিং করছি এবং প্রায়শই নিজেকে একটি দ্বিধায় ফেলে এসেছি।

দুটি সমাধান রয়েছে -

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

যখন আমার কাছে কঠোর পারফরম্যান্স এসএলএর দেখা মেটাতে হবে না এবং এমনকি সহজ সমাধানটি পারফরম্যান্স এসএলএ পূরণ করতে পারে তখন আমার কোন সমাধানটির জন্য চেষ্টা করা উচিত? সহজ সমাধানের জন্য আমি আমার সহকর্মী বিকাশকারীদের মধ্যে অসন্তুষ্টি বোধ করেছি।

যদি আপনার পারফরম্যান্স এসএলএ একটি সাধারণ সমাধান পূরণ করতে পারে তবে সর্বাধিক অনুকূল জটিল সমাধান নিয়ে আসা ভাল অনুশীলন?

Comments

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

— মশা

"সর্বাধিক অনুকূল" কি এখনও "যথেষ্ট ভাল" হবে না? তারপরে সেই সাথেই থাকুন।

হাঁ। " লে মিউক্স ইস্ট ল'নেমি ডু বিয়েন। " ভোল্টায়ার। ("পারফেক্ট হ'ল শত্রু" ") পারফরম্যান্স টেস্টিং অন্যথায় না বলা পর্যন্ত যথেষ্ট যথেষ্ট যথেষ্ট।

— ডেভিড হামেন

আমি দেখতে পেলাম (সাধারণভাবে) সহজভাবে দক্ষ বোঝায়। তাই প্রায়শই আপোষ করার দরকার পড়ে না।

— ড্যান

"দেখে মনে হয় যে সংযোজন করার মতো আর কিছুই নেই, তখন যখন সিদ্ধি লাভ হয় না, তবে যখন অপসারণ করার মতো আর কিছুই নেই” "- এন্টোইন ডি সেন্ট-

— এক্সুপেরি

Answer 1

যখন আমার কাছে কঠোর পারফরম্যান্স এসএলএর দেখা মেটাতে হবে না এবং এমনকি সহজ সমাধানটি পারফরম্যান্স এসএলএ পূরণ করতে পারে তখন আমার কোন সমাধানটির জন্য চেষ্টা করা উচিত?

সরল এক। এটি স্পেকের সাথে মিলিত হয়েছে, এটি বোঝা সহজ, এটি বজায় রাখা আরও সহজ এবং সম্ভবত এটি পুরোপুরি কম বগী।

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

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

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

Comments

আপনার উত্তরটি খুব সহায়ক

— মুভিফাস্ট

যতটা সম্ভব সহজ, তবে সহজ নয়; যত দ্রুত সম্ভব, তবে দ্রুত নয়; ইত্যাদি

— ব্যবহারকারী 606723

"সন্দেহ হলে, নিষ্ঠুর শক্তি ব্যবহার করুন";)

— টিডামার্স

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

— TheAtomicOption

Answer 2

সংক্ষিপ্ত উত্তর: জটিলগুলির তুলনায় সহজ সমাধানগুলি পছন্দ করুন এবং KISS এবং YAGNI নীতিগুলি মনে রাখবেন

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

এছাড়াও, স্মার্ট হওয়ার চেষ্টা করা এবং আপনার অ্যাপ্লিকেশন তৈরি করার সময় কিছু অ্যাড-হক অপ্টিমাইজেশান স্থাপন করা ভাল অভ্যাস নয় এবং এটি আপনার সমাধানকে অতিরিক্ত জটিল করে তুলতে পারে। যেমনটি জানা যায়, "premature optimization is the root of all evil"- নুথের বই থেকে

Comments

@ মনোজগম্বার, কোনও সমস্যা নেই এবং এর প্রোগ্রামিং হিসাবে আমাদের প্রথমে যত্ন নেওয়া উচিত এর মূল বিষয়টি।

— EL ইউসুবোভ

Answer 3

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

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

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

Comments

নোট করুন যে এর অর্থ এই নয় যে আপনি প্রথমে ভাল প্রয়োগকরণ লিখবেন না।

@ থরবজর্নরভানএন্ডারসন: অবশ্যই প্রথম দুটি বিষয়ই এটির।

— সাইমন

@ সিমন উক্তিটি প্রায়শই chooseালুভাবে বেছে নেওয়ার অজুহাত হিসাবে ব্যবহৃত হয়

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

— বুহব

@ ThorbjørnRavnAndersen অযোগ্য লোকেরা অজুহাতে যে কোনও কিছু ব্যবহার করবে। মূল চিন্তার মানটির কোনও প্রভাব নেই।

— সাইমন

Answer 4

সরলতা নির্ভরযোগ্যতার পূর্বশর্ত । আপনার যদি একটি সাধারণ সমাধান কার্যকর হয় তবে তা সর্বদা এটির জন্য যান! একটি অপ্টিমাইজড প্রোগ্রামের কাজটি করার চেয়ে কোনও কাজের প্রোগ্রামকে অনুকূলকরণ করা অনেক সহজ। এছাড়াও মুর আইন সম্পর্কে ভুলবেন না : আপনার সাধারণ সমাধানটি যদি আজ পারফরম্যান্সের লক্ষ্যগুলি পূরণ করে তবে এটি সম্ভবত এক বা দুই বছরে তাদের ^{1 টি} পিষ্ট করবে ।

---

¹ এখানে কোনও গ্যারান্টি নেই, কারণ জিমি হোফা যেমন নীচে তার মন্তব্যে উল্লেখ করেছেন, মুরের আইনটির সীমা রয়েছে।

Comments

আপনি মুরের অন্যান্য আইনের কথা ভুলে গিয়েছিলেন যা বলেছিল, "ওফস, আমার প্রথম আইন সম্পর্কে .." দুঃখিত আফসোস, মুরের আইনটি আর নেই (পাং পাং)। আপনার বাকী অংশটির সাথে আমি একমত নই, আমি সেখানে অন্তত সাবধানতা অবলম্বন করব last

— জিমি হোফা

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

— ব্যবহারকারী 606723

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

— dasblinkenlight

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

— ব্যবহারকারী 606723

Answer 5

যদি আপনার পারফরম্যান্স এসএলএ একটি সাধারণ সমাধান পূরণ করতে পারে তবে সর্বাধিক অনুকূল জটিল সমাধান নিয়ে আসা ভাল অনুশীলন?

অনুকূল একটি অস্পষ্ট শব্দ!

শেষ পর্যন্ত, যদি জটিলটি বজায় রাখার অনেক ঝুঁকি থাকে এবং সাধারণটি যদি "যথেষ্ট ভাল" হয় তবে আমি সর্বদা সরলটির পাশে থেকে ভুল করি।

জটিলটি যে কোনও একটির পক্ষে যথেষ্ট ভাল না হওয়ার ঝুঁকিতে যুক্ত করুন, তবে KISS সম্ভবত সঠিক উত্তর।

Answer 6

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

সুতরাং নীচের লাইনে - আমি এটি যথাসম্ভব নমনীয়ভাবে ডিজাইন করব, তবে নমনীয়তার জন্য খুব সরলতার জন্য ত্যাগ করব না।

Answer 7

কোনটির দাম কম?

বেশিরভাগ সময়, একটি সহজ সমাধান যা সামান্য ধীর গতিতে পারফরম্যান্সের ক্ষেত্রে পুরোপুরি গ্রহণযোগ্য হবে এবং সরলতা এটি বিকাশ, পরিচালনা এবং অবশেষে প্রতিস্থাপনের জন্য সস্তা করে তোলে aper

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

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

Answer 8

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

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

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

Answer 9

এটি সর্বদা একটি কঠিন প্রশ্ন এবং আমি উত্তরগুলি এক দিক দিয়ে দুলতে দেখি, তাই আমি অন্যদিকে খেলা খেলব, যদিও আমি দাবি করি না যে উত্তরটি সঠিক, এটি খুব নরম এবং কেস বাই কেস বিষয় topic

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

এটিকে একটি ইন্টারফেসে মুড়িয়ে রাখুন, এটি তার নিজের একটি অ্যাসেমব্লিতে রাখুন, সম্ভবত এটি নিজের নিজস্ব সমস্ত প্রক্রিয়াও। ফাঁস এড়াতে যতটা সম্ভব ঘন বিমূর্ত প্রাচীর দিয়ে যতটা সম্ভব looseিলে .ালাভাবে এটি তৈরি করুন । ভবিষ্যতে রিগ্রেশনগুলি সংরক্ষণ করতে এর জন্য প্রচুর ইউনিট পরীক্ষা লিখুন।

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

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

Answer 10

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

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

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

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

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