আমার কেন মাইক্রো পারফরম্যান্স এবং দক্ষতা সম্পর্কে যত্ন নেওয়া উচিত?

Question

সি / সি ++ পৃষ্ঠাগুলিতে অনেকগুলি প্রশ্নোত্তর, বিশেষভাবে বা অপ্রত্যক্ষভাবে মাইক্রো পারফরম্যান্স সম্পর্কিত সমস্যাগুলি (যেমন একটি পরোক্ষ বনাম সরাসরি বনাম ইনলাইন ফাংশনটির ওভারহেড) বা O (N ² ) বনাম O (N লগ এন) অ্যালগরিদম ব্যবহার করে একটি 100 আইটেমের তালিকা।

আমি সর্বদা মাইক্রো পারফরম্যান্স সম্পর্কে কোনও উদ্বেগ এবং ম্যাক্রো পারফরম্যান্স সম্পর্কে সামান্য উদ্বেগের সাথে কোড করি না, যতক্ষণ না জানি বা না জানা পর্যন্ত আমার কোনও সমস্যা রয়েছে।

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

Comments

+1, ভাল সাধারণ প্রশ্ন।

— iammilind

+1 ভাল প্রশ্ন..আমি 2 টি ট্যাগ যুক্ত করেছি .. আশা করি এটি সম্পর্কে আপনার আপত্তি নেই।

আমি দুটি দুর্দান্ত উক্তি 1) "অকালীন অপটিমাইজেশন সমস্ত মন্দের মূল।" 2) আপনার 80% সময় আপনার কোডের (20/20 বিধি) 20% ব্যয় করবে।

— জেমস খুরি

আমি আমার ও (এন * এন) উদাহরণ সম্পর্কে বেশ কয়েকটি উত্তর লক্ষ্য করেছি। আমি স্পষ্টতই 100 টি আইটেমের একটি তালিকা নির্দিষ্ট করেছি, তবুও তারা এখনও জোর দিয়ে থাকে যে ও (nlogn) আরও ভাল, স্পষ্টভাবে কর্মক্ষমতা উন্নতি উল্লেখ করে যদি তালিকাটি, ফল্টের মধ্যে, 1000 বা মিলিয়নে যায়। এই মাইক্রো অপ্টিমাইজেশান আবেশটি কি কারণ প্রগ্রেমাররা সম্ভাব্য ভবিষ্যতের প্রয়োজনীয়তার পরিবর্তে প্রকৃত নিরামকের প্রয়োজনীয়তার জন্য প্রোগ্রাম করছেন? (আমি এর আগে কোথায় শুনেছি ...)

— ম্যাটনজ

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

— StuperUser

Answer 1

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

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

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

Comments

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

— মাইক ডিসিমোন

"একবার" কতবার হয় তার উপর নির্ভর করে। চলমান অবস্থায় ./configure, আমি বলার উদ্যোগ নেব যে স্ক্রিপ্টটি চালিত প্রোগ্রামগুলিতে রান সময়টির 75% সময় "আরম্ভকরণ" কোডে ব্যয় হতে পারে। 25-50% এমনকি ডায়নামিক লিঙ্কিংয়ে ব্যয় হতে পারে।

— আর ..

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

— এডিএ-কিএ মার্ট-ওরা-ওয়াই

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

— mattnz

ওপি জিজ্ঞাসা করল কেন এত যত্ন নেওয়া, এবং আমি যদি দেখতে না পাই যে এই প্রতিক্রিয়াটি আসলে কীভাবে এই প্রশ্নের উত্তর দিয়েছে, যদি না ওপি কেউ "এটির জন্য উদ্বিগ্ন হবেন না!" শুনতে শুনতে আগ্রহী না হন!

— লাল-ময়লা

Answer 2

আমি মনে করি আপনার তালিকার সমস্ত কিছুই মাইক্রো অপ্টিমাইজেশান, যা সাধারণত বাদে বাদ দেওয়া উচিত নয়

100 আইটেমের তালিকায় একটি ও (এন * এন) বনাম ও (এনলগএন) অ্যালগরিদম ব্যবহার করে

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

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

Comments

"সঠিক অ্যালগরিদম নির্বাচন করা কখনই কোনও মাইক্রো-অপ্টিমাইজেশন হয় না" "

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

— আর ..

মজার ব্যাপার। মাইক্রো অপ্টিমাইজেশান সম্পর্কে একটি থ্রেডে, অনেক মন্তব্যকারী উত্তরগুলি মাইক্রো-অপ্টিমাইজ করে। ;)

— সুরক্ষিত করুন

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

— নিকি

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

— ক্যাসি প্যাটন

Answer 3

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

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

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

---

একই কাজের অন্য ক্ষেত্রে, গ্রাহক তাদের পরিসংখ্যান প্রক্রিয়া নিয়ন্ত্রণ ব্যবস্থাতে প্রতিক্রিয়া সময় সম্পর্কে অভিযোগ করছিলেন। আমার আগে দলটি "সফটওয়্যার পিএলসি" সিস্টেমটি ডিজাইন করেছিল যেখানে অপারেটররা সংকেতগুলি মিশ্রণ এবং ট্রিপিং সুইচগুলির জন্য বুলিয়ান যুক্তি ব্যবহার করতে পারে। তারা এটিকে সরল ভাষায় লিখেছিলেন, যাকে আমরা আজ "ডোমেন নির্দিষ্ট ভাষা" বলি। যেমনটি আমি স্মরণ করি এটি দেখতে অনেকটা অন্যরকম ((A1 + B1) > 4) AND (C1 > C2)ছিল।

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

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

নতুন কোডটি প্রায় রক্ষণাবেক্ষণের মতো ছিল না, কারণ আমি একটি কাস্টম সংকলক তৈরি করেছি । তবে পারফরম্যান্স সুবিধাটি রক্ষণাবেক্ষণের অসুবিধাকে ছাড়িয়ে যায়।

---

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

এই ধরণের জিনিসগুলি সর্বদা উঠে আসে।

---

সুতরাং .... কখনও কখনও আপনি রক্ষণাবেক্ষণযোগ্য, সহজেই লেখার কোড চান want কখনও কখনও আপনি কোড চান যা দ্রুত চলে। ট্রেড অফ হ'ল প্রতিটি প্রকল্পের জন্য আপনার করা উচিত প্রকৌশল সিদ্ধান্ত।

Comments

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

— কোডসইনচাওস

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

— ওয়েববিডেভ

Answer 4

যদি আপনি বড় চিত্রগুলি প্রক্রিয়াকরণ করে এবং প্রতিটি পিক্সেল ধরে পুনরাবৃত্তি করেন তবে পারফরম্যান্সের টুইটগুলি সমালোচনাযোগ্য হতে পারে।

Comments

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

— সিস্টেমওয়াইড বিটস

পারি সমালোচনামূলক, কিন্তু IS শুধুমাত্র সমালোচনামূলক পর আপনি এখন হতে এটা প্রমাণিত থাকেন এবং যদি আপনি এটি প্রোফাইল থাকেন হতে যেখানে আপনি কি মনে করেন সমস্যা। (ইঙ্গিত: সম্ভবত এটি নেই))

— আমার সঠিক মতামত

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

— টুইটকে

Answer 5

সংস্কৃতির পিছনে কী কারণে আমি আপনাকে কিছুটা বলি ।

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

• বৃহত্তর (> 2 জি) ফাইল পড়তে সক্ষম হতে আমাদের মূ programming় প্রোগ্রামিং কৌশলগুলি করতে হত ...
• আমরা এক্সিকিউটেবল আকার সম্পর্কে চিন্তা করতাম ...
• আমাদের প্রোগ্রামগুলি কতটা স্মৃতি গ্রহণ করছিল তা নিয়ে আমরা চিন্তা করতাম ...
• আমরা নিয়মিতভাবে অ্যালগরিদমিক সময় বনাম স্পেস ট্রেড-অফ সিদ্ধান্ত ...
• এমনকি ব্যাক এন্ড উপর, আমরা ছিল একটি শালীন কোন হ্যান্ডেল করতে কিছু জন্য সি সিজিআই প্রোগ্রামসমূহ বা সি ++ লিখতে। আরপিএসের ... এটি দ্রুততার কয়েকটি আদেশ ছিল ।
• আমরা ডেলফি / সি ++ / ভিবি এর মধ্যে পারফরম্যান্সের যোগ্যতার উপর পরীক্ষা চালাতাম!

খুব অল্প লোককেই আজ এই বিষয়গুলি নিয়ে চিন্তা করতে হবে।

যাইহোক, 10 বছর আগে আপনি এখনও আপনার সফ্টওয়্যারটি 56kb মডেমের মাধ্যমে ডাউনলোড করা এবং 5 বছরের পুরনো পিসিতে চালিত হওয়া নিয়ে চিন্তিত ছিলেন ... 1996 সালের পিসিগুলি কতটা কৃপণ ছিল তা কি আপনার মনে আছে? 4GB হার্ড ড্রাইভ, 200Mhz প্রসেসর এবং 128Mb র‌্যামের বিবেচনা করুন ...

এবং 10 বছর আগে সার্ভারগুলি? ডেলের "পরবর্তী প্রজন্মের" সার্ভারটির দাম cost 2000, এবং এটি 2 (!) 1Ghz পেন্টিয়াম প্রসেসর, 2 জিবি বা রাম এবং একটি 20 জিবি হার্ড ড্রাইভ নিয়ে এসেছিল।

এটি কেবল একটি ভিন্ন বলগেম ছিল এবং সেই সমস্ত "সিনিয়র" ইঞ্জিনিয়ারদের যাদের 10 বছরের অভিজ্ঞতা রয়েছে (ছেলেরা সম্ভবত আপনার প্রশ্নের উত্তর দিচ্ছেন), সেই পরিবেশে তাদের দাঁত কেটেছিলেন ।

Comments

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

— ব্লারফ্লায়

লুপ আনওয়্যান্ডিং <শ্যাড্ডার>

— লাল-ময়লা

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

— gbjbaanb

Answer 6

এখানে ইতিমধ্যে 10 টি উত্তর রয়েছে এবং কিছু সত্যই ভাল, তবে এটি আমার ব্যক্তিগত পোষা প্রাণী ...

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

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

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

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

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

Comments

+1 টি এই বিকাশ ভাড়াটে তাদের জন্য employability ফ্যাক্টরের মধ্যে একটি হল Shrinkwrap সফ্টওয়্যার ও বাণিজ্যিক ওয়েব সাইট । গ্রাহকের অভিশাপের চেয়ে প্রতিরোধ কম ব্যয়বহুল।

— রওয়ং

Answer 7

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

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

Comments

+1 - দ্রষ্টব্য: "পারফরম্যান্স" ট্যাগ সহ বেশিরভাগ প্রশ্নগুলি সম্ভবত সেই নমুনা ত্রুটির অংশ: পি

— বিলি ওনিল

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

— আর ..

আপনি যখন কিছু চতুর সঙ্গে লেনদেন করছেন, প্রায়ই সহজে বলে মনে হয় চতুর সমস্যা থেকে একটি বিরতি নিয়ে এবং আপনার সময় সম্পর্কে কিনা ব্যবহার করা উচিত উদ্বেজক নষ্ট করা থেকে i++বা++i

— Carson63000

@ কারসন 000৩০০০: হ্যাঁ এটি সম্পূর্ণরূপে নমুনাগুলিকে স্কু করতে পারে। অথবা তারা কেন আমার operator ++সংকলন করল না সে সম্পর্কে প্রশ্নের উত্তর দিতে সময় ব্যয় করে।

— রোবং

Answer 8

অন্যান্য উত্তরগুলির মধ্যে একটিতে এমবেডেড সিস্টেমগুলির উল্লেখ রয়েছে এবং আমি এটিতে প্রসারিত করতে চাই।

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

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

উদাহরণস্বরূপ, মাইক্রোকন্ট্রোলারগুলির এসটিএম 32 পরিবার 24 মেগাহার্টজ, 16 কেবি ফ্ল্যাশ এবং 4 কেবি র‌্যাম থেকে 120 মেগাহার্টজ, 1 এমবি ফ্ল্যাশ এবং 128 কেবি র‌্যামে চলে ।

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

Comments

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

— জেফ

Answer 9

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

অন্য অর্ধেকটি তাদের কৌতূহল থেকেই আসে যে তারা ধাতবটির আরও কাছে যেতে পারে। এগুলি মূলত নিম্ন-স্তরের ভাষা হচ্ছে ...

Comments

+1: "প্যাথলজিকাল পারফরম্যান্স" বিশ্বের যে কোনও ব্যক্তির সাথে ভাষা বা প্ল্যাটফর্ম নির্বিশেষে ঘটতে পারে তা উল্লেখ করার মতো বিষয়। পরীক্ষা-নিরীক্ষণ এবং পাঠ্য বিচ্ছিন্নতার জন্য নিম্ন-স্তরের ভাষায় পুনঃ-প্রয়োগের ক্ষমতা আরও অন্তর্দৃষ্টি সরবরাহ করতে পারে তবে সর্বদা কার্যক্ষম সমাধান সরবরাহ করে না। উদাহরণ: "আমি জানি আমি এটি সমাবেশে করতে পারি - তবে এটি আংশিক-বিশ্বাসের পরিবেশে চালানো দরকার!"

— রওয়ং

Answer 10

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

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

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

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

Comments

হুম .. আমি দ্রুত পুনরাবৃত্তির জন্য পয়েন্টার পাটিগণিত ব্যবহার করি না - এটি বহুগুণ এবং লুপ প্রতি নির্দেশ যুক্ত করুন আপনি সূচক ভিত্তিক বা পয়েন্টার ভিত্তিক পুনরাবৃত্তি ব্যবহার করছেন কিনা। আমি যদিও এটি ব্যবহার করি, কারণ এটি সাধারণত সূচক-ভিত্তিক পুনরাবৃত্তির চেয়ে আরও স্পষ্ট।

— বিলি ওনিল

পয়েন্টার পাটিগণিত ডাব্লু / ই এর চেয়ে দ্রুত নয়।

Answer 11

প্রোগ্রামাররা এত যত্ন কেন করে? তাদের মস্তিষ্কে জনবহুল ধারণা রয়েছে, যেমন পারফরম্যান্স সমস্যার সমাধান করার আগে তারা তাদের জানার আগে তাদের সমাধান করে এবং অনুমান করার সময় বুঝতে না পারে ।

এটি মুশকিল, কারণ আমার অভিজ্ঞতায় কিছু পারফরম্যান্স সমস্যা রয়েছে যা আমাদের সময়ের আগে চিন্তা করা উচিত । তারা কী তা জানার জন্য অভিজ্ঞতা লাগে।

এটি বলেছিল, আমি যে পদ্ধতিটি ব্যবহার করি তা আপনার মতো, তবে একই নয়:

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

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

আমি কী বোঝাতে চাইছি তার একটি ধাক্কা দিয়ে দেওয়া উদাহরণ এখানে ।

Answer 12

সত্যি বলতে কী, এটি আপনার লক্ষ্য কী এবং আপনি পেশাদারভাবে প্রোগ্রাম করছেন বা শখ হিসাবে তা নির্ভর করে depends

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

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

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

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

Comments

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

— বিলি ওনিল

তারা তা করে না, তবে তারা চাইলে তাদের অবশ্যই কাজ করার জন্য আরও সময় আছে।

আমি বিপরীতে তর্ক করব। পেশাদার হিসাবে কিছু নিয়ে কাজ করার জন্য আমি দিনে 8 ঘন্টা বা তারও বেশি সময় পেয়েছি। আমার শখের প্রকল্পগুলির জন্য আমি 1, প্রতিদিন 2 ঘন্টা পাই।

— বিলি ওনিল

Answer 13

100 আইটেমের তালিকায় ও (এন 2) বনাম ও (এনলগএন) অ্যালগরিদম ব্যবহার করে।

আমি সম্প্রতি একই পরিস্থিতিতে ছিল। আমি আইটেমের একটি অ্যারে ছিল। প্রত্যাশিত ক্ষেত্রে তালিকায় দুটি (!) আইটেম ছিল এবং সবচেয়ে খারাপ ক্ষেত্রেও আমি চারটি বা সম্ভবত আটটির বেশি আশা করি না।

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

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

Answer 14

সংক্ষিপ্ত শক্তি ব্যবহার

এর একটি উত্তর আছে যা আমি সর্বদা মনে করি এই আলোচনা থেকে অনুপস্থিত এবং যা আমাকে খানিকটা বিরক্ত করে - একত্রিত শক্তি ব্যবহার ।

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

কিন্তু যখন কয়েক হাজার, বা এমনকি কয়েক মিলিয়ন ব্যবহারকারী আপনার কোড ব্যবহার করেন, তখন সমস্ত অতিরিক্ত অদক্ষতা যুক্ত হয়ে যায়। যদি আপনার সরঞ্জামটি কোনও সিপিইউকে প্রতিদিন মাত্র দশ সেকেন্ডের জন্য ঘুমের রাজ্যে প্রবেশ করতে বাধা দেয় এবং এক মিলিয়ন ব্যবহারকারী এটি ব্যবহার করেন, আপনার অকার্যকর অ্যালগরিদমটি কেবল প্রতিদিন অতিরিক্ত 140 কিলোওয়াট ^[1] ব্যবহার করেছে ।

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

---

^{[1] আমি সবেমাত্র এটি করেছি, 10 মিলিয়ন সেকেন্ডের বার 50 ওয়াটস। সঠিক চিত্রটি অনেক কিছুর উপর নির্ভর করে।}

Comments

"মোবাইল" ম্যাজিক শব্দটি উল্লেখ করে আপনার এখনই শুরু করা উচিত। ডেস্কটপ প্ল্যাটফর্মে চলাকালীন, একটি অ্যাপ্লিকেশন যা সেকেন্ডে 60 বার ফ্রেম আঁকার জন্য 1/100 সেকেন্ড সময় নেয় "দ্রুত পর্যাপ্ত" হবে; দশগুণ পারফরম্যান্স উন্নতি ব্যবহারকারীর শূন্য পার্থক্য করতে পারে। একটি মোবাইল প্ল্যাটফর্মে, তবে, 90% সিপিইউ ব্যবহারের জন্য চলে এমন একটি অ্যাপ্লিকেশন 10% এ চালানোর চেয়ে ব্যাটারিগুলিকে দ্রুত গজগজ করতে পারে।

— সুপারক্যাট

Answer 15

কখনও কখনও আপনার কাছে কেবল অ্যালগরিদম থাকে যা লিনিয়ার সময়ের চেয়ে ভাল হতে পারে না যার জন্য এখনও শক্তিশালী পারফরম্যান্স চাহিদা রয়েছে।

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

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

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

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

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

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

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

Answer 16

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

Answer 17

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

Comments

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

— স্টেফ

Answer 18

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

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

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

কখনও কখনও আমার লাইভে, আমি শিখেছি উপসর্গ বৃদ্ধি দ্রুত হয় ...

for (int i = 0; i < MAX; ++i)

... পোস্টফিক্স ইনক্রিমেন্টের চেয়ে:

for (int i = 0; i < MAX; i++)

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

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

Answer 19

আমি কি খুব ভাগ্যবান হয়েছি যে এটি সম্পর্কে খুব বেশি চিন্তা করতে হবে না, বা আমি একজন খারাপ প্রোগ্রামার?

আপনি কি আপনার প্রয়োজনীয়তা সম্পর্কে যত্নশীল? যদি পারফরম্যান্সের প্রয়োজনীয়তা না থাকে তবে এটি নিয়ে চিন্তা করবেন না। এটিতে কোনও উল্লেখযোগ্য সময় ব্যয় করা আপনার নিয়োগকর্তার পক্ষে বিরক্তি।

কিছুটা হলেও পারফরম্যান্স সর্বদা প্রয়োজন। আপনি যদি এটির কথা না ভেবে এটিকে আঘাত করতে পারেন তবে আপনি এটি সম্পর্কে চিন্তা না করে যুক্তিযুক্ত are

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

আমার প্রশ্ন হ'ল কেন এটি বিশাল সংখ্যক প্রোগ্রামার এত যত্ন করে? এটি কি বেশিরভাগ বিকাশকারীদের পক্ষে সত্যিই একটি সমস্যা,

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

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

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

কেউ কেউ তাদের কোডটি কী অপঠনযোগ্য তা থেকে একটি বিকৃত রোমাঞ্চ পান। অন্যদের দ্বারা তৈরি কোড বোঝার জন্য তাদের কঠোরভাবে দেখার ভোগ করতে হয়েছিল তাই এখন তাদের প্যাকব্যাকের পালা।

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

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

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

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