উন্নয়নের শুরুতে বা উন্নয়নের শেষে কোনও সফ্টওয়্যারকে আরও ভাল পারফরম্যান্সের জন্য অনুকূলকরণ করা কখন ভাল?

Question

আমি একজন জুনিয়র সফটওয়্যার বিকাশকারী এবং আমি ভাবছিলাম কখন আরও ভাল পারফরম্যান্সের (গতি) জন্য কোনও সফ্টওয়্যার অনুকূলিত করার সেরা সময় হবে?

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

Comments

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

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

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

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

পরিণতি: এটি কি / হয় সিদ্ধান্ত হয়, বা অন্যদের পিছনে ফেলে কিছুদূর আগে কার্য সম্পাদনের সিদ্ধান্ত নেওয়া গুরুত্বপূর্ণ হতে পারে?

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

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

— পিটার বি

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

— লাইভ

Answer 1

এক নম্বর জিনিসটি সর্বদা এবং চিরকাল পঠনযোগ্যতা হওয়া উচিত। যদি এটি ধীর হয় তবে পঠনযোগ্য হয় তবে আমি এটি ঠিক করতে পারি। যদি এটি ভাঙা হয় তবে পঠনযোগ্য হয় তবে আমি এটি ঠিক করতে পারি। যদি এটি অপঠনযোগ্য হয় তবে আমাকে অন্য কাউকে জিজ্ঞাসা করতে হবে এটি করারও কি ছিল?

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

কেবল দুটি জিনিসই আমাকে এই মোড থেকে বাইরে নিয়ে যায়:

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

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

Comments

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

— পিটার বি

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

— ডক ব্রাউন

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

— ডক ব্রাউন 13

@ পিটারবি: বা আপনার কাছে এমন একজন ক্লায়েন্ট আছেন যিনি তার অর্থ ফেরত পেতে চান কারণ তারা যে পণ্যটি কিনেছিল তারা বগি তাই তারা এটি ব্যবহার করতে পারে না।

— ডক ব্রাউন

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

— candied_orange

Answer 2

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

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

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

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

Answer 3

যখন আরও ভাল পারফরম্যান্স (গতি) জন্য কোনও সফ্টওয়্যার অনুকূলিত করার সেরা সময় হবে।

আপনার মন থেকে ধারণাটি সরিয়ে দিয়ে শুরু করুন যে গতি হিসাবে পারফরম্যান্স একই জিনিস। পারফরম্যান্স যা ব্যবহারকারী বিশ্বাস করেন কর্মক্ষমতা ।

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

আপনি যদি আপনার অ্যাপ্লিকেশনটিকে দ্বিগুণ দ্রুত করে থাকেন এবং আপনি মেশিনে সমস্ত মেমরি ব্যবহার করেন এবং ক্র্যাশ করেন তবে ব্যবহারকারীর যত্ন নেই যে এটি এখন দ্বিগুণ দ্রুত।

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

ধরে নিই যে সফ্টওয়্যারটি পরিচালনা করা অত্যন্ত বড় এবং জটিল নয়

এটি একটি ভয়ানক অনুমান।

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

এটিকে অনুকূলকরণের শুরুতে আরও বেশি সময় ব্যয় করা ভাল কি আমার কেবলমাত্র এমন সফ্টওয়্যারটি বিকাশ করা উচিত যা সমস্ত কার্যকারিতা সঠিকভাবে সম্পাদন করে এবং তারপরে আরও ভাল পারফরম্যান্সের জন্য এটি অপ্টিমাইজ করতে এগিয়ে যায়?

আপনি সেখানে একটি ফাঁকা পৃষ্ঠায় বসে আছেন এবং লিখছেন void main() {}আপনি কি অনুকূলিতকরণ শুরু করেন? অপ্টিমাইজ করার মতো কিছু নেই! সঠিক অর্ডারটি হ'ল:

• এটি সংকলন করুন
• এটি সঠিক করুন
• এটি মার্জিত করুন
• দ্রুত কর

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

তবে সেখানে একটি পদক্ষেপ নিখোঁজ রয়েছে। বাস্তব সঠিক অনুক্রমে হল:

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

Comments

"পারফরম্যান্স যা ব্যবহারকারী বিশ্বাস করেন পারফরম্যান্স" " - প্রকৃতপক্ষে, একদা ব্যবহারকারীর অভিজ্ঞতা আসলে ভাল যখন জিনিস আমরা সময় লাগবে আশা করি সময় লাগবে: webdesignerdepot.com/2017/09/when-slower-ux-is-better-ux

— svidgen

হতে পারে "বিজ্ঞান ব্যবহার করুন" এর পরিবর্তে "বিজ্ঞানী হন" :)

— নীল

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

— জর্জিও 16

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

— এরিক লিপার্ট

Answer 4

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

সুতরাং, একটি মধ্যম স্থল পদ্ধতির আমার মতে সেরা হবে; এটির উপর খুব বেশি জোর দেবেন না, তবে পুরোপুরি পারফরম্যান্সকে অবহেলা করবেন না।

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

User user = getUser();
int totalAmount;
for (Order o : user.getOrders()) {
  totalAmount += o.getTotalAmount();
} 

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

এখানে এসকিউএল কোয়েরির পরিমাণ আপনাকে অবাক করে দিতে পারে। অবশ্যই এটি আপনার সত্তাগুলি কীভাবে কাঠামোগত হয় তার উপর নির্ভরশীল।

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

Answer 5

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

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

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

তো তুমি কি কর? ভাল, কিছু জিনিস।

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

2. পুনরাবৃত্তি হওয়া। সিস্টেমটি তুলনামূলকভাবে নতুন হলে বেসলাইন কর্মক্ষমতা ব্যবস্থা গ্রহণ করুন এবং সদ্য চালু হওয়া কোডটি খুব বেশি কর্মক্ষমতা হ্রাস পাচ্ছে না তা নিশ্চিত করতে মাঝে মাঝে পুনরায় পরীক্ষা করুন।

3. খুব তাড়াতাড়ি overoptimize করবেন না। আপনি কখনই জানেন না কী গুরুত্বপূর্ণ হতে চলেছে এবং কোনটি গুরুত্বপূর্ণ হবে না; উদাহরণস্বরূপ, যদি আপনার প্রোগ্রামটি নিয়মিত I / O এর জন্য অপেক্ষা করে থাকে তবে একটি সুপার স্ট্রিং পার্সিং অ্যালগরিদম সাহায্য করতে পারে না।

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

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

এই ক্রিয়াকলাপগুলির বেশিরভাগ প্রকল্পের শুরু বা শেষের জন্য নয় তবে অবিরত উপস্থিত থাকতে হবে ।

Answer 6

আমি একজন জুনিয়র সফটওয়্যার বিকাশকারী এবং আমি ভাবছিলাম কখন আরও ভাল পারফরম্যান্সের (গতি) জন্য কোনও সফ্টওয়্যার অনুকূলিত করার সেরা সময় হবে?

2 টি খুব আলাদা চরম রয়েছে তা বুঝুন।

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

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

এই চরমের মাঝে একটি বিশাল ধূসর অঞ্চল।

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

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

Answer 7

কোড লেখা সবচেয়ে সহজ যেটি না পারফর্মেন্ট বা রক্ষণাবেক্ষণযোগ্য। পোরফর্মেন্ট কোড লেখা শক্ত to রক্ষণাবেক্ষণযোগ্য কোডটি লেখা এখনও শক্ত। এবং কোড রক্ষণ করা সবচেয়ে কঠিন যে এটি উভয়ই রক্ষণাবেক্ষণযোগ্য এবং পারফরম্যান্ট।

তবে, পারফরম্যান্ট কোড রক্ষণাবেক্ষণযোগ্য করার চেয়ে, রক্ষণাবেক্ষণযোগ্য কোড সম্পাদন করা আরও সহজ।

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

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

এর পরে, প্রথমে আপনার কোডটি রক্ষণাবেক্ষণযোগ্য করে তোলার উপর ফোকাস করুন। এর দ্বারা, আমি বলতে চাই:

1. আপনি যতটা কঠোরভাবে উদ্বেগগুলি আলাদা করুন (উদাহরণস্বরূপ, ব্যবসায়িক যুক্তির সাথে ডেটা অ্যাক্সেসের মিশ্রণ করবেন না)
2. যেখানে সম্ভব সেখানে কংক্রিটের ধরণের পরিবর্তে অ্যাবস্ট্রাক্ট প্রকারের রেফারেন্স
3. আপনার কোডটিকে পরীক্ষামূলক করে তোলেন

রক্ষণাবেক্ষণযোগ্য কোডটি অপ্টিমাইজ করা অনেক সহজ যখন পরিসংখ্যানগুলি দেখায় যে এটি প্রয়োজন।

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

পারফরম্যান্স টিউনিংয়ের জন্য অটোমেটেড ডিপ্লোয়মেন্ট স্ক্রিপ্ট এবং স্ক্রিপ্টেড অবকাঠামোও খুব কার্যকর, এগুলি আপনাকে দ্রুত পুনরাবৃত্তি করার অনুমতি দেয়; এর অন্যান্য সুবিধাগুলি উল্লেখ না করা।

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

Answer 8

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

অদ্ভুত মামলা

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

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

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

যতটা সম্ভব লেট

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

পরে অনুকূলিত করার জন্য কোনটি শ্বাস প্রশ্বাসের ঘরটি ডিজাইন করুন

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

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

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

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

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

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

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

Answer 9

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

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

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

Answer 10

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

পারফরম্যান্স এছাড়াও ব্যবহারের সহজ। কিছু ব্যবহারকারীর পরিবর্তে 1 সেকেন্ডে 2 কী স্ট্রোকটি টাস্কের চেয়ে 10 সেকেন্ডে 1 কীস্ট্রোক একটি কাজ করতে চায়। এই জাতীয় জিনিসগুলির জন্য আপনার ডিজাইনের সীসা জিজ্ঞাসা করুন। আমি ব্যবহারকারীদের কাছে এর আগে স্টাফ নিতে পছন্দ করি না। শূন্যতায় তারা এক্স বলতে পারে তবে একবার তারা কার্যক্ষম প্রাক-প্রকাশের সাথে কাজ করার পরে তারা ওয়াই বলতে পারে।

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

আপনি কি তথ্যের জন্য একটি ট্রিপ তৈরি করছেন যা সেশনের সময় পরিবর্তন হয় না। যদি তাই হয় এটি সেশন শুরুতে পেতে এবং এটি মেমরি হোল্ড।

সংগ্রহের ধরণটি বাছাই করার সময় কার্যকরী, গতি এবং আকার বিবেচনা করুন।

আপনি কি নিশ্চিত যে আপনার সংগ্রহে থাকা আইটেমগুলি রাখা দরকার? একটি সাধারণ সমস্যা হ'ল একটি ফাইল থেকে সমস্ত লাইন একটি তালিকার মধ্যে পড়ে এবং তারপরে তালিকাটিতে একবারে এক লাইনে প্রক্রিয়া করা হয়। একবারে ফাইলটি এক লাইনে পড়া এবং তালিকাটি এড়িয়ে যাওয়া আরও বেশি দক্ষ।

আপনি একবার লুপ করতে এবং তিনটি জিনিস করতে পারলে আপনি কি তিনবার লুপ করছেন?

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

অনেকগুলি পারফরম্যান্স হ'ল ক্লিন কোডও।

অকাল অপটিমাইজেশন রয়েছে এবং সেখানে কেবল সাধারণ জ্ঞানের জিনিসপত্র রয়েছে যা সত্যই বেশি সময় নেয় না।

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