কম বিলম্বিত কোডটি কি কখনও কখনও "কুশ্রী" হতে হয়?

Question

(এটি মূলত যাদের স্বল্প বিলম্বিত সিস্টেমগুলির নির্দিষ্ট জ্ঞান রয়েছে তাদের উদ্দেশ্য, যাতে লোকেরা কেবল অসমর্থিত মতামত দিয়ে উত্তর না দেয়)

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

এটি যুক্তি দাঁড়ায়- কুরুচিপূর্ণ দেখায় কে তা যত্নশীল করে তোলে (এতক্ষণ ধরে রাখার মতো) - আপনার যদি গতির প্রয়োজন হয়, আপনার গতি দরকার?

আমি এই ধরনের ক্ষেত্রে যারা কাজ করেছেন তাদের কাছ থেকে শুনতে আগ্রহী হবে।

Comments

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

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

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

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

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

— ব্লারফ্লার

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

— জেমস

@ কারসন 000৩০০০০, ব্যবহারকারী ১৫৯৮৮৯০ এবং অন্য যে কেউ আগ্রহী: যদি প্রশ্নটি বন্ধ হয়ে যায় তবে আমাদের মেটা সাইটে বন্ধের বিষয়ে নির্দ্বিধায় জিজ্ঞাসা করুন , মন্তব্যগুলিতে একটি বন্ধ করার বিষয়ে আলোচনা করার খুব একটা দরকার নেই, বিশেষত এমন একটি বন্ধ যা ঘটেনি । এছাড়াও, মনে রাখবেন যে প্রতিটি বদ্ধ প্রশ্ন পুনরায় খোলা যেতে পারে, এটি বিশ্বের শেষ নয়। অবশ্যই মায়ানরা ঠিক থাকলে, এক্ষেত্রে আপনারা সবাইকে জেনে ভাল লাগছিল!

— ইয়ানিস

Answer 1

আপনি কি মনে করেন "চমৎকার" অবজেক্ট অরিয়েন্টেটেড কোড লেখার এবং খুব [sic] লো লেটেন্সি কোড লেখার মধ্যে কোনও বাণিজ্য আছে?

হ্যাঁ।

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

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

Comments

"এটি কাজ করুন, তারপরে এটি দ্রুত করুন"। এই উত্তরটি আমি প্রশ্নটি পড়ার সাথে সাথে বলতে শুরু করেছিলাম এমন সমস্ত কিছুকে কভার করে।

— কারসন 63000

আমি "পরিমাপ, অনুমান করবেন না" যুক্ত করব

— মার্টিজান ভারবার্গ

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

— এরিক পুনরায়

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

— স্টিভ 314

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

— ব্র্যান্ডন

Answer 2

হ্যাঁ, আমি যে উদাহরণ দিচ্ছি তা সি ++ বনাম জাভা নয়, তবে এসেম্বলি বনাম সিওবিওএল যেমন এটি আমি জানি।

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

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

বলা হচ্ছে, মন্তব্যগুলির উদার ব্যবহারের ফলে প্রোগ্রামার কার্যকারিতা এবং রক্ষণাবেক্ষণ অনেক বেড়ে যায়, কোড যতই কুৎসিত হোক না কেন।

Answer 3

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

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

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

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

সুতরাং, একজন ব্যবসায়ের মালিকের উচিত:

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

---

এই বাণিজ্য বন্ধগুলি পরিস্থিতিতে অত্যন্ত সুনির্দিষ্ট।

পরিচালক এবং পণ্য মালিকদের অংশগ্রহণ ব্যতীত এগুলি সর্বোত্তমভাবে সিদ্ধান্ত নেওয়া যায় না।

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

---

হ্যাঁ, এটি সাধারণত সত্য যে দ্রুত কোডটি সাধারণত লিখিত কোডের থেকে পৃথক দেখায়। যে কোনও কোড আলাদা হয় সেগুলি পড়তে আরও সময় লাগবে। এটি কদর্যতা বোঝায় কিনা দর্শকের চোখে।

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

সাধারণত উচ্চ-স্তরের কাঠামোগত পরিবর্তন প্রয়োজন হয় না এমন সিমডের সাধারণত নিম্ন-স্তরের পাঠযোগ্যতার উপর মারাত্মক প্রভাব থাকে (শর্ত থাকে যে এপিআই বাধা-প্রতিরোধের বিষয়টি মাথায় রেখে ডিজাইন করা হয়েছে)।

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

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

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

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

---

না, দ্রুত কোড অবজেক্ট-ওরিয়েন্টেডনেসের সাথে দ্বন্দ্বের প্রয়োজন নেই।

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

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

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

Answer 4

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

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

Answer 5

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

লুপ আন্রোলিংয়ের মতো অন্যান্য অনুকূলিতকরণগুলি যখন প্রয়োজন হয় তখন একটি পরিষ্কার ফ্যাশনে যুক্ত করা যায়।

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

আমি খুঁজে পেয়েছি যে 80/20 নিয়মটি আমি অনুকূলিত করেছি কোডটিতে প্রযোজ্য। থাম্বের নিয়ম হিসাবে আমি এমন কোনও কিছুই অনুকূলিত করি না যা কমপক্ষে ৮০% সময় নেয় না। আমি তখন লক্ষ্য করি 10 (এবং সাধারনত অর্জন) 10 গুণ কর্মক্ষমতা বৃদ্ধি। এটি প্রায় 4 ভাগে কর্মক্ষমতা উন্নত করে। বেশিরভাগ অপটিমাইজেশন যা আমি প্রয়োগ করেছি কোডটি উল্লেখযোগ্যভাবে কম "সুন্দর" করে নি। আপনার মাইলেজ পরিবর্তিত হতে পারে.

Answer 6

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

অন্যথায়, কখনও কখনও এটি একটি ঘাতক ইন্টারফেসের সাথে একটি সুন্দর বাক্সে কুৎসিত রাখার পক্ষে যথেষ্ট পারফরম্যান্স জয়ের পক্ষে যথেষ্ট তবে আমার অভিজ্ঞতা হিসাবে, এটি একটি খুব বিরল দ্বিধা।

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

Comments

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

— রবিং

ওওপিশ কথোপকথনে শব্দের একটি দুর্বল পছন্দ ছিল বাস্তবায়ন। আমি এটি পুনরায় ব্যবহারের সহজ এবং সম্পাদনার দিক থেকে বোঝাতে চাইছি। # 2, আমি কেবল একটি বাক্য যুক্ত করেছি যে এটি 2 প্রতিষ্ঠিত করতে মূলত আমি যে বিন্দুটি তৈরি করছিলাম is

— এরিক পুনরায়

Answer 7

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

কুশ্রী কোড, আমার কাছে যে কোডটি, পঙ্কিল দুর্বল বিবেচিত, এবং / অথবা হল অকারণে জটিল। আমি মনে করি না আপনি কোডটিতে এমন কোনও বৈশিষ্ট্য চান যা সম্পাদন করতে হবে।

Answer 8

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

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

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

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

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

পারফরম্যান্সের জন্য ডিজাইনিং

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

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

মোটা ইন্টারফেস ডিজাইন

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

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

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

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

একটি মোটা নকশা সহ আরও কার্যকর লকিং নিদর্শন সরবরাহ করার এবং কোডের মধ্যে সমান্তরালতা কাজে লাগানোর সহজ উপায় আসতে ঝোঁক (মাল্টিথ্রেডিং একটি বিস্তৃত বিষয় যা আমি এখানে এড়িয়ে যাব)।

মেমরি পুল

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

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

টাইপ সিস্টেমগুলি পৃথক মেমরি

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

সি ++ এর একটি সাধারণ উদাহরণ হ'ল পলিমারফিজম প্রয়োজন এমন ক্ষেত্রে, যেখানে প্রাকৃতিক প্রলোভন একটি সাধারণ-উদ্দেশ্যে মেমরির বরাদ্দকারীদের বিরুদ্ধে সাবক্লাসের প্রতিটি উদাহরণ বরাদ্দ করা হয়।

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

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

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

একসাথে ফিরে স্মৃতি ফিউজিং

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

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

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

অরুপ

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

বিপজ্জনক

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

সৌন্দর্য

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

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

টি এল; ডিআর

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

Answer 9

আলাদা হতে হবে না, তবে আমি যা করি তা এখানে:

1. এটি পরিষ্কার এবং রক্ষণাবেক্ষণযোগ্য লিখুন।

2. কি কর্মক্ষমতা নির্ণয়ের , এবং সমস্যার এটা আপনাকে বলে না বেশী আপনি অনুমান সমাধান করুন। গ্যারান্টিযুক্ত, তারা আপনার প্রত্যাশা থেকে আলাদা হবে।

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

তাহলে কি কোনও বাণিজ্য আছে? আমি সত্যিই তাই মনে করি না।

Answer 10

আপনি কুরুচিপূর্ণ কোড লিখতে পারেন যা খুব দ্রুত এবং আপনি খুব সুন্দর কোডও লিখতে পারেন যা আপনার কুৎসিত কোডের মতো দ্রুত। বাধা আপনার কোডটির সৌন্দর্য / সংস্থা / কাঠামোতে নয় তবে আপনি যে কৌশলগুলি বেছে নিয়েছেন সেগুলিতে থাকবে। উদাহরণস্বরূপ, আপনি কি নন-ব্লকিং সকেট ব্যবহার করছেন? আপনি কি একক থ্রেডেড ডিজাইন ব্যবহার করছেন? আন্তঃ থ্রেড যোগাযোগের জন্য আপনি কি লক-মুক্ত সারিতে ব্যবহার করছেন? আপনি কি জিসির জন্য আবর্জনা তৈরি করছেন? আপনি কি সমালোচনামূলক থ্রেডে কোনও ব্লকিং I / O অপারেশন করছেন? আপনি দেখতে পাচ্ছেন এটির সৌন্দর্যের সাথে কোনও সম্পর্ক নেই।

Answer 11

শেষ ব্যবহারকারীর কী দরকার?

• কর্মক্ষমতা
• বৈশিষ্ট্য / কার্যকারিতা
• নকশা

কেস 1: অপটিমাইজড খারাপ কোড

• কঠোর রক্ষণাবেক্ষণ
• ওপেন সোর্স প্রকল্প হিসাবে খুব কমই পঠনযোগ্য

কেস 2: অপটিমাইজড ভাল কোড

• সহজ রক্ষণাবেক্ষণ
• খারাপ ব্যবহারকারীর অভিজ্ঞতা

সমাধান?

সহজ, কোডের পারফরম্যান্সের সমালোচনামূলক টুকরোটিকে অনুকূল করুন

উদাহরণ:

একটি প্রোগ্রাম যা 5 পদ্ধতি নিয়ে গঠিত , এর মধ্যে 3 ডেটা পরিচালনার জন্য, 1 ডিস্ক পাঠের জন্য, অন্যটি ডিস্ক লেখার জন্য

এই 3 ডেটা ম্যানেজমেন্ট পদ্ধতি দুটি I / O পদ্ধতি ব্যবহার করে এবং তাদের উপর নির্ভর করে

আমরা আই / ও পদ্ধতিগুলি অনুকূল করে তুলব।

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

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

আমি চিন্তা করছি..

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