আপনার বৃহত সফ্টওয়্যার প্রকল্পে অনুশীলনে জটিলতা কীভাবে পরিমাপ করবেন?

Question

বিশ্ববিদ্যালয়ে, আমাদের অ্যালগরিদম কোর্সে, আমরা হ্যাশ টেবিল বা দ্রুত সাজানোর মতো অনুশীলনে ব্যবহৃত বিভিন্ন সাধারণ অ্যালগরিদমের জটিলতার সুনির্দিষ্টভাবে গণনা করতে শিখি।

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

এটা করার কোন উপায় আছে? বা অনুশীলনকারীরা বিশ্বব্যাপী পুরোপুরি প্রয়োগটিকে পুরোপুরি বিবেচনা না করে পুরো অ্যাপ্লিকেশনটিকে দ্রুততর করার জন্য একটি দ্রুত অ্যালগরিদম ব্যবহার করে "স্থানীয়ভাবে" নির্ভর করছেন?

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

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

Comments

1) উন্নতির জন্য পয়েন্টগুলি খুঁজতে এটির একটি পরীক্ষার পদ্ধতির প্রয়োজন। বেঞ্চমার্ক পরীক্ষা, স্থায়িত্ব পরীক্ষা, গতিশীল পরীক্ষা (প্রতিটি উপাদান মেমরি / সিপিইউ মেট্রিক্স পর্যবেক্ষণ করে)। 2) উন্নতি করার জন্য পয়েন্টগুলি সন্ধান করার পরে, আপনি এই পয়েন্টগুলির মূল কারণটি খুঁজে পাবেন। 3) সঠিক কারণ বজায় রেখে মূল কারণ সমাধানের জন্য একটি সমাধান অনুসন্ধান করুন।

— ওভাররেচেন্জ

এই পরীক্ষাগুলির জন্য আপনার পয়েন্ট 1

— তে

বিগ হে বিশ্লেষণ আপনাকে জানায় না যে কীভাবে অ্যালগরিদম সম্পাদন করবে। এটি আপনাকে জানায় যে পারফরম্যান্স কীভাবে বাড়বে , স্কেল হবে n।

— জন উ

Answer 1

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

সুতরাং স্বতন্ত্র টুকরো তাকানো শুরু করা প্রায়শই সেরা পন্থা। এই কারণেই প্রোফাইলিং ( ডেভিড আরনোর উত্তরে বর্ণিত হিসাবে ) ঠিক আছে, যেহেতু এটি আপনাকে কোডের উল্লিখিত 5% চিহ্নিত করতে সহায়তা করে যেখানে অনুকূলকরণ আপনাকে "বাকের পক্ষে সবচেয়ে বড় ব্যাং" দেবে। "পুরো অ্যাপ্লিকেশনটি" অনুকূলকরণের ক্ষেত্রে অত্যধিক মাত্রার অতিরিক্ত ঝুঁকির ঝুঁকি রয়েছে এবং আপনি যদি 95% এমনকি 10 এর ফ্যাক্টর দ্বারা অনুকূল করেন তবে এটি প্রায়শই কোনও পরিমাপযোগ্য প্রভাব ফেলবে না। আরও নোট করুন যে প্রোফাইলটি আপনাকে যে কোনও অনুমানের অ্যালগরিদম জটিলতার অনুমানের চেয়ে বেশি উপায় বলে দেয়, যেহেতু একটি সাধারণ অ্যালগরিদম যার জন্য O (N ^ 3) পদক্ষেপ প্রয়োজন তারপরেও একটি জটিল অ্যালগরিদমের তুলনায় দ্রুততর হতে পারে যার জন্য O (N লগ (এন)) প্রয়োজন হয় যথেষ্ট ছোট।

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

সাধারণ অপ্টিমাইজেশন কৌশলগুলি অন্তর্ভুক্ত

• অ্যালগরিদম এবং ডেটা স্ট্রাকচারের ব্যবহার উন্নত করা

• প্রাক্তনের সূক্ষ্ম সুর

• কিছু বাস্তব গরম দাগে মাইক্রো-অপ্টিমাইজেশান

• অ্যাসেম্বলি কোড বা সিইউডিএ ব্যবহার করে সমালোচনা বিভাগগুলি পুনর্বিবেচনা

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

Answer 2

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

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

Comments

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

— ফ্রাঙ্ক হিলিমান

@ ফ্র্যাঙ্কহিল্যান, আমি মনে করি যে এখানে বক্তব্যটি হ'ল পারফরম্যান্স একটি ব্যবহারিক উদ্বেগ এবং কেবল ব্যবহারিকভাবে পরিমাপ করা যায়। আপনি নিজের সফ্টওয়্যারটির বাধা খুঁজে পেতে গণিত ব্যবহার করবেন না, এমনকি যদি আপনি একবার গণিত (অ্যালগরিদম) ব্যবহার করে এটি সমাধান করতে পারেন।

— ওয়াইল্ডকার্ড

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

— ওয়াইল্ডকার্ড

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

— ফ্র্যাঙ্ক হিলিমান

@ উইল্ডকার্ড: আপনি সঠিক, তবে ফ্র্যাঙ্কও খুব সঠিক যে এই পোস্টটি প্রশ্নের উত্তর দেয় না।

— ডক ব্রাউন

Answer 3

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

আমার প্রথম পদক্ষেপটি হ'ল একটি বিস্তৃত আর্কিটেকচার ডায়াগ্রামে আমার হাত পেতে বা একটি নিজে তৈরি করা। সফ্টওয়্যারটিতে কোন উপাদানগুলি নিয়ে পদক্ষেপ নেওয়া হয় এবং প্রতিটি পদক্ষেপে কতক্ষণ সময় নেয় তা নির্ধারণ করুন।

এছাড়াও, কীভাবে উপাদানগুলি একে অপরের সাথে যোগাযোগ করে তা নির্ধারণ করুন। এটি সমস্ত পার্থক্য করতে পারে।

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

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