আপনি কোন পয়েন্টে পারফরম্যান্স সম্পর্কে চিন্তা করা শুরু করবেন?


16

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

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

হালনাগাদ

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


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

দাহাহলিং, এটা কি স্পষ্ট নয়? আপনি যখন আপনার অডিশনের জন্য অপেক্ষা!
ম্যাট এলেন

উত্তর:


24

কর্মক্ষমতা বিবেচনার ডিফারাল কখনও কখনও এই বাক্যাংশের ভুল প্রয়োগের উপর ভিত্তি করে:

অকালীন অপটিমাইজেশন হ'ল সমস্ত অশুভের মূল।

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

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

বিকাশের (এবং অকাল) অপ্টিমাইজেশন ছাড়াই ভাল পারফরম্যান্স অর্জনের জন্য উন্নয়নের সময় আপনি অনেকগুলি জিনিস করতে পারেন:

  1. একটি বুদ্ধিমান, সুচিন্তিত আর্কিটেকচার ব্যবহার করুন।
  2. ডেটা স্ট্রাকচার সঠিকভাবে ব্যবহার করুন।
  3. প্রযুক্তি (গ্রন্থাগার, ফ্রেমওয়ার্ক) ব্যবহার করুন যা পর্যাপ্তভাবে সম্পাদন করে।

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


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

@ অ্যাডাম - আপনাকে ধন্যবাদ! আমি পুরোপুরি একমত! আমি ব্যক্তিগতভাবে বুঝতে পারি না কেন আপনি কোডের একগুচ্ছ লেখার আগে আপনি কেন চিন্তাভাবনা করার চেষ্টা করতে চান না।
কগনিট্রনিক

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

20

এখানে যা ভাববেন তা নয়:

  • এর ++iচেয়ে দ্রুত i++?
  • এর switchচেয়ে দ্রুত if?
  • আমার কি inlineআমার কাজ করা উচিত?
  • ভার্চুয়াল ফাংশন ধীর?
  • সি ++ / জাভা / সি # কি অন্যের চেয়ে দ্রুত / ধীর?
  • ব্লা, ব্লা, ...

এখানে যা ভাববেন তা এখানে:

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

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

আপনি যদি এই সমস্ত কাজটি করেন তবে আপনার একটি পরিষ্কার নকশা রয়েছে। তারপরে পর্যায়ক্রমে আপনি এটি বিকাশ হিসাবে, প্রোফাইল। ( এলোমেলোভাবে বিরতি দেওয়া পদ্ধতিটি আমি নির্ভর করি)


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

@ রবার্ট: হ্যাঁ দু: খিত। আমাকে কেবল আমার ভার্চুয়াল বিয়ারে কাঁদতে হবে :-)
মাইক ডুনলাভে

3

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


3

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

80% কার্যকারিতা হ'ল সমস্যাটির জন্য সঠিক অ্যালগরিদম এবং ডেটা কাঠামোটি বাছাই করছে; একটি দুর্বলতম অপ্টিমাইজড কোকসোর্ট এখনও প্যান্টগুলিকে মারতে চলেছে গড় ক্ষেত্রে অত্যন্ত অনুকূলিত বুদ্বুদ সাজানোর (সবচেয়ে খারাপ ক্ষেত্রে এটি একটি ড্র)।

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


1 যেখানে "নির্ভুলতা" অর্থ "স্পেসিফিকেশন পূরণ", যা "বাগ-মুক্ত" এর সমার্থক নয়।


1
কিছু স্পেসিফিকেশন একটি পারফরম্যান্স প্রয়োজনীয়তা সংজ্ঞায়িত করে, আপনার আদেশে এর কী প্রভাব ফেলবে?
বেন এল

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

2

"ভাল" পারফরম্যান্স কী তা জানার পরে আপনার অভিনয় সম্পর্কে চিন্তাভাবনা শুরু করা উচিত। অন্য কথায়, নীচের চৌকাঠটি কী তা চিহ্নিত করার আগে পারফরম্যান্স সম্পর্কে চিন্তা শুরু করা ভুল হবে:

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

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

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


1

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

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


1

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

প্রয়োজনীয়তা ডকুমেন্টেশন আপনাকে শত ঘন্টা সময় সাশ্রয় করবে যা অন্যথায় অপ্রয়োজনীয় প্রক্রিয়াগুলিতে নষ্ট হবে।


1

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

  1. প্রথমে আপনি কী করছেন এবং কীভাবে করছেন তা সম্পর্কে কিছুটা চিন্তা করার চেষ্টা করে একটি বৈশিষ্ট্য তৈরি করুন (পারফরম্যান্স সম্পর্কে একটু সময় চিন্তা করুন তবে বেশি নয়)
  2. এটা পরীক্ষা করো
  3. একবার এটিকে আরও উন্নত করার জন্য সত্যিকারের প্রয়োজন আছে কিনা তা নিয়ে ভাবতে শুরু করুন (সাধারণত আপনি অভ্যাস করেন না তবে কোনও ক্ষেত্রে আপনি হয়ত পারেন)।

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

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


1

কর্মক্ষমতা সম্পর্কে চিন্তাভাবনার একটি নিরাপদ স্থগিতের একটি উপায় রয়েছে: যেখানেই সম্ভব ডোমেন নির্দিষ্ট ভাষা ব্যবহার করা।

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

এটি ভেরু রক্ষণাবেক্ষণের দিক থেকেও অনেক ভাল পদ্ধতির।


1

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

কর্মক্ষমতা সম্পর্কে সত্যই একটি ভাল পাঠ্য নিবন্ধটি: কম্পিউটার পারফরম্যান্স শেল গেম

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

  • সিপিইউ
  • ডিস্ক
  • অন্তর্জাল
  • স্মৃতি

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


0

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

  • আপনার কি প্রচুর স্মৃতি আছে? - আপনি একটি "অল ইন-মেমরি" ডেটা স্ট্রাকচারের সাথে আরও ভাল পারফরম্যান্স পাবেন তবে আপনার যদি পর্যাপ্ত মেমরির অদলবদল না করে তবে আপনার কর্মক্ষমতা হারাবে।
  • আপনার কি অধ্যবসায় দরকার? একটি ডাটাবেস অখণ্ডতা দেয় তবে উপরের "অল ইন-মেমরি" ডেটা কাঠামোর চেয়ে ধীর। অনেক ধীর।
  • আপনি ফলাফল ক্যাশে করতে পারেন? বার্নিশ যে সাহায্য করতে পারেন! http://www.varnish-cache.org/

তালিকা এবং উপর যায়।

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


0

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


0

তত্ত্বের ক্ষেত্রে কমপক্ষে, আপনি একবার বিটা পরীক্ষায় চলেছেন এবং তার আগে না হয়ে পারফরম্যান্সের কথা ভাবেন।

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

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

আছে HTH


0

এটা নির্ভর করে. এটি 80/20 নিয়মটি মাথায় রাখার জন্য দরকারী: অ্যাপ্লিকেশনটির কোডের সর্বাধিক (বলুন 80%) কার্য সম্পাদনে কোনও লক্ষণীয় পার্থক্য তৈরি করার জন্য প্রায়শই যথেষ্ট কার্যকর করা হয় না। আপনার অবশিষ্ট 20% যেখানে অ্যাপ্লিকেশনটি প্রায় 80% সময় নির্বাহের সময় ব্যয় করতে বাধ্য তার উপর আপনার দৃষ্টি নিবদ্ধ করা দরকার।

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

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


0

এটি নির্ভর করে আপনি কোন পর্যায়ে উন্নয়নের পর্যায়ে আছেন

1) আপনি যদি আপনার সফ্টওয়্যারটির কার্যকারিতা তৈরির ক্ষেত্রে এটি চালিয়ে যান এবং নিশ্চিত হন যে এটি ঠিকঠাকভাবে কাজ করে (যেমন, পছন্দসই এবং দক্ষতার সাথে)।

2) একবার ব্লকগুলি সংহত করার পরে, আপনি রিসোর্স হোগারের ইঙ্গিত পাবেন, সেখানে আপনার অনুকূলকরণের জন্য জায়গা রয়েছে।


0

যদি আপনাকে পারফরম্যান্স সম্পর্কে ভাবতে শুরু করতে হয় তবে আপনি সমস্যায় পড়েছেন। আপনি সবসময় কর্মক্ষমতা সম্পর্কে চিন্তা করা উচিত। আসলে, আমি সন্দেহ করি যে ভাল প্রোগ্রামাররা তাদের মনস্থির না হওয়া সত্ত্বেও পারফরম্যান্স সম্পর্কে চিন্তাভাবনা করতে চলেছে, একটি «পুরুষরা প্রতি সাত সেকেন্ডে সেক্স সম্পর্কে ভাবেন» ফ্যাশন ..

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

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

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

আপনি যদি এমন কোনও দ্রুত কৌশল সম্পর্কে জানেন যা কোনও কোডের টুকরোটির কার্যকারিতা প্রায় অবশ্যই উন্নতি করে তবে তা করবেন না।

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

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

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


0

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

তারপরে যতটা সম্ভব সিস্টেমটি বাস্তবায়ন করুন। যদি পারফরম্যান্সের সমস্যা দেখা দেয় তবে অনুকূলিত করুন।

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

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


0

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

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

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


0

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


0

আমি কখন এটি সম্পর্কে চিন্তা শুরু করব? এতে আমার কতটা প্রচেষ্টা করা উচিত? এটি প্রকল্পের ককবার্ন স্কেলের উপর নির্ভর করে । (অন্য কথায়, ভাল অভিনয় না করার ঝুঁকি কী?)

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

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

তারপরে, আপনার প্রকল্পের প্রকৃতি এবং এর ককবার্ন স্কেলের উপর নির্ভর করে:

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

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

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

    • পারফরম্যান্সের পরিসংখ্যান বিশ্লেষণ ও প্রতিবেদনের দায়িত্বে থাকতে আপনার দলে কাউকে নিযুক্ত করুন।
    • পারফরম্যান্স বৈশিষ্ট্য সম্পর্কে তত্ত্ব তৈরি করুন, পরীক্ষাগুলি দিয়ে যাচাই করুন এবং সরলিকৃত কমপ সায়েন্স মডেলগুলি থেকে আপনার ভবিষ্যদ্বাণীগুলির সাথে তুলনা করুন।
    • *

0

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

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


আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.