আপনি যখন কোনও ফাংশনের বিগ ও এক্সিকিউশন সময় পরিবর্তন করেন তখন আপনি এটিকে কী বলেছিলেন [বন্ধ]

Question

ধরা যাক আমার একটি ফাংশন রয়েছে যা O(n^2)সময় মতো একটি ডেটাবেস বাছাই করে । আমি এটি রিফ্যাক্টরিং সম্পর্কে যেতে চাই যাতে এটি O(n log(n))সময়মতো চলে এবং তাই করতে আমি ফিরে আসার মান এবং ইনপুটগুলির সমতুল্য রেখে অপারেশনটি চালিত করার মৌলিক উপায়ে পরিবর্তন করব।

আমি এই রিফ্যাক্টরিং ক্রিয়াকলাপটিকে কী বলি?

"স্পিডিং-আপ-আইফাইজিং" একেবারেই সঠিক বলে মনে হচ্ছে না, যেহেতু আপনি যে বড় ও গতিটি চালিয়েছিলেন তা পরিবর্তন না করে আপনি একটি অ্যালগরিদমকে দ্রুত যেতে পারবেন।

"সরলকরণ "ও ঠিক মনে হচ্ছে না।

এই ক্রিয়াকলাপটিকে আমি কী বলি?

হালনাগাদ

আমি যে সর্বোত্তম উত্তরটি খুঁজে পেতে পারি তা হ'ল অ্যাসিমপোটিক সময়ের জটিলতা হ্রাস করা।

Comments

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

— নাট

এটি রিফ্যাক্টরিং নয়

— 19.38 এ আনিলিগুস্টি

কড়া কথায় বলতে গেলে, ফাংশন যা O(log(n))সময়মতো চলে তাও O(n^2)সময়মতো চলে। এর অর্থ O(n^2)"চতুষ্কোণের চেয়ে দ্রুত বৃদ্ধি পায় না"। আপনি সম্ভবত থেতা (লগ (এন)) বোঝাতে চেয়েছিলেন যার অর্থ "যত দ্রুত বৃদ্ধি পায় log(n)"। en.wikipedia.org/wiki/...

— Džuris

<pedantic> আপনি কোনও ক্রিয়াকলাপের বড় ও নির্বাহের সময় পরিবর্তন করেন নি। একটি ফাংশন একটি ডোমেন এবং কোডোমেনের মধ্যে একটি সম্পর্ক এবং বাস্তবায়নের সময় আপনার শাস্তি মানব প্রচেষ্টা ব্যতীত বিদ্যমান। পরিবর্তে আপনি একটি আরও ভাল পারফর্মিং অ্যালগরিদম পেয়েছেন যা ফাংশনটি </pedantic> <human> ভাল কাজ </

— uman

@ থিওনলিগুস্তি: এটি নির্ভর করে। যদি ফাংশনটি পূর্বে জটিলতার জন্য গ্যারান্টি / গ্যারান্টি দেয় তবে এটি রিফ্যাক্টরিং নয়। যদি এটি কোনও গ্যারান্টি না দেয় তবে এটি রিফ্যাক্টরিং oring যদি এটি গ্যারান্টি না দেওয়ার বিষয়েও স্পষ্ট হয় তবে এটি বিশেষত একটি রিফ্যাক্টরিং।

— ফ্রেসনেল

Answer 1

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

এটি করতে গিয়ে আমি অপারেশনটি চালানোর মৌলিক উপায়ে পরিবর্তন করব

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

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

Comments

সত্যি? প্রয়োজনীয়তাগুলি পরিবর্তন না হলে আমি রিফ্যাক্টরিং সঠিক বলে মনে করব। সুতরাং .. না যদি ফাংশনটিকে বুদ্বুদর্ট বলা হয় তবে হ্যাঁ যদি এটি ঠিক সাজান

— ইওয়ান

@ ইভান হ্যাঁ, আইনসম্মতভাবে একটি রিফ্যাক্টরিং একটি পারফরম্যান্স-অপ্টিমাইজেশন হতে পারে, তবে পূর্ববর্তীটি খুব সাধারণ এবং পরিবর্তনের প্রভাবটিকে যথাযথভাবে ক্যাপচার করেন না।

— Deduplicator

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

— সেন্টিনেল

@Steve। একমত। আমি কেবল এই sensকমত্যে যোগ দিয়েছিলাম যে বিগ হে উন্নতিগুলি অ্যালগরিদমিক উন্নতির প্রতিনিধিত্ব করে, সেই অ্যালগরিদমগুলি কীভাবে প্রতিনিধিত্ব করা হয় বা বজায় রাখা হয় তার উন্নতি নয়। অন্য কথায়, ক্রিয়াকলাপটি একটি পুনর্লিখন

— সেন্টিনেল

@ স্টিভ: হ্যাঁ, আমি এটি জানতাম, আমার উত্তরে একটি নোট যুক্ত করার কথা ভেবেছিল। আমার সম্পাদনাটি একটি ছোট, ধূসর অঞ্চল রয়েছে তা পরিষ্কার করার জন্য কেবল একটি নোট ছিল।

— ডক ব্রাউন

Answer 2

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

Answer 3

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

সতর্কতা : অ্যাসিম্পটোটিক সময়ের জটিলতা হ্রাস করা ব্যবহারিক প্রসঙ্গে উপযুক্ত হওয়ার মতো নয়। প্রায়শই অ্যাসিম্পোটোটিকভাবে অপ-অনুকূল অ্যালগরিদম ব্যবহার করা হয় কারণ ইনপুটগুলির পরিসীমাতে প্রোগ্রামটি প্রকৃতপক্ষে কম অনুকূল অ্যালগরিদমগুলি আরও ভাল সম্পাদন করে।

Answer 4

এটি প্রসঙ্গনির্ভর হবে।

"একটি চতুর্ভুজ রানটাইম পারফরম্যান্স বাগ ঠিক করা" সাধারণত আমি যা দেখি। যাইহোক, এটি নির্ধারণের যোগ্য কিনা (কোনও কোড পরিবর্তন) প্রসঙ্গ নির্ভর।

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

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

সফ্টওয়্যার কর্মক্ষমতা সম্পর্কে প্রচুর গ্রাহকের অভিযোগ এই দুটি বিভাগের মধ্যে পড়ে:

• সম্পূর্ণ সিস্টেম (সফ্টওয়্যার এবং হার্ডওয়্যার) আনুমানিক ব্যবহারের ভিত্তিতে নির্দিষ্ট করা হয়েছিল। গত সপ্তাহে, সবকিছু ঠিকঠাক হয়, একটি নির্দিষ্ট কার্যকারিতা 5 সেকেন্ডেরও কম সময় নেয়। এই সপ্তাহে, একটি আপডেট ইনস্টল করার পরে, একই কার্যকারিতাটি 1 মিনিটেরও বেশি সময় নেয়।

  • এটি পূর্ববর্তী মানদণ্ডের পারফরম্যান্সের সাথে তুলনা। গ্রাহক ভবিষ্যতের কর্মক্ষমতা একটি মানব সময়-স্কেলের (সেকেন্ড থেকে মিনিট) এর পরম ইয়ার্ডস্টিকের কাছে ধারণ করে।

• আমি সিস্টেমে 100 টি কাজ জমা দিয়েছি। একক কাজের জন্য যে সময় লাগে তার তুলনায় এটি কেন 400x প্রক্রিয়া করতে সময় নিচ্ছে?

  • গ্রাহক প্রসেসিংয়ের সময়টি লিনিয়ার হওয়ার প্রত্যাশা করে। আসলে, গ্রাহক বুঝতে বা গ্রহণ করতে পারবেন না যে লিনিয়ারের চেয়ে ধীর গতির কার্য রয়েছে tasks

এই কারণে, কোনও গ্রাহক উভয়ই সত্য হলে কার্যকর করার সময়টিকে বাগ হিসাবে বিবেচনা করবে:

• রৈখিক চেয়ে ধীর
• লক্ষণীয় (যেমন টিপিক্যাল টাস্ক মাপের পরে মানব সময়সীমার মধ্যে পড়ে (সেকেন্ড বা মিনিটের চেয়ে বেশি দীর্ঘ))

আইনী যুক্তি যা ব্যাখ্যা করে যে চতুর্ভুজ রানটাইম অ্যালগরিদম কোনও সমস্যা সৃষ্টি করে না (যেমন কোনও কোড পরিবর্তনের যোগ্য নয়):

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

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

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

Answer 5

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

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

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

Answer 6

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

স্কেলিবিলিটি উন্নত করেছে। শুনেছি।