বড় অ্যাপ্লিকেশনগুলিতে এসটিএলকে এড়ানো উচিত?


24

এটি একটি অদ্ভুত প্রশ্ন হিসাবে শোনায়, তবে আমার বিভাগে আমরা নিম্নলিখিত পরিস্থিতি নিয়ে সমস্যায় পড়েছি:

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

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

স্পষ্টতই আমরা ইনপুট / আউটপুট পরামিতিগুলিকে স্ট্যান্ডার্ড সি ++ টাইপ দ্বারা প্রতিস্থাপন করতে পারি এবং ফাংশনের অভ্যন্তরে একবারে এসটিএল অবজেক্ট তৈরি করতে পারি, তবে এটি পারফরম্যান্স ড্রপের কারণ হতে পারে।

আপনি যদি কোনও অ্যাপ্লিকেশন তৈরির বিষয়ে বিবেচনা করছেন, তবে এটি একক পিসি আর পরিচালনা করতে পারে না এমনটি বড় হতে পারে, এই সিদ্ধান্তে পৌঁছানো কি ঠিক আছে, আপনার অবশ্যই কোনও প্রযুক্তি হিসাবে এসটিএল ব্যবহার করা উচিত নয়?

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

+-----------+-----------+----
| Machine1  | Machine2  | ...
| App_Inst1 | App_Inst2 | ...
|           |           |    
| DLL1.1    | DLL2.1    | ...
| DLL1.2    | DLL2.2    | ...
| DLL1.x    | DLL2.x    | ...
+-----------+-----------+----

App_Inst1 হ'ল মেশিন 1 এ ইনস্টল হওয়া অ্যাপ্লিকেশনটির উদাহরণ, অন্যদিকে অ্যাপ_ইনস্ট 2 মেশিন 2 এ ইনস্টল হওয়া একই অ্যাপ্লিকেশনটির উদাহরণ।
DLL1.x হ'ল একটি ডিএলএল, মেশিন 1 এ ইনস্টল করা হয়, এবং ডিএলএল 2.x একটি ডিএলএল, মেশিন 2 এ ইনস্টল করা হয়।
ডিএলএলএক্স .১ এক্সপোর্ট করা ফাংশন 1 coversেকে রাখে।
ডিএলএলএক্স.২ এক্সপোর্ট করা ফাংশন 2 coversেকে রাখে।

এখন মেশিন 1 এ আমি ফাংশন 1 এবং ফাংশন 2 চালাতে চাই। আমি জানি যে এটি মেশিন 1 ওভারলোড করবে, তাই আমি অ্যাপ্লিকেশন 2-এ একটি বার্তা প্রেরণ করতে চাই, সেই অ্যাপ্লিকেশনটিকে ফাংশন 2 সম্পাদন করতে বলছি।

ফাংশন 1 এবং ফাংশন 2 এর ইনপুট / আউটপুট প্যারামিটারগুলি হ'ল এসটিএল (সি ++ স্ট্যান্ডার্ড টাইপ লাইব্রেরি) অবজেক্টস এবং নিয়মিত আমি গ্রাহককে অ্যাপ_আইএনএসটি 1, অ্যাপ_ইনস্ট 2, ডিএলএলএক্স.আই এর আপডেটগুলি করার আশা করতে পারি (তবে তাদের সবকটিই নয়, গ্রাহক মেশিন 1 আপগ্রেড করতে পারে তবে মেশিন 2 নয়, বা কেবল অ্যাপ্লিকেশনগুলি আপগ্রেড করুন তবে ডিএলএল বা বিপরীতে নয়, ...)। স্পষ্টতই যদি ইন্টারফেস (ইনপুট / আউটপুট পরামিতি) পরিবর্তন হয় তবে গ্রাহক সম্পূর্ণ আপগ্রেড করতে বাধ্য হন।

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

আমি আশা করি এর মাধ্যমে আমি কিছু প্রশ্ন / সন্দেহ দূর করেছি।


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

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

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

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

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

উত্তর:


110

এটি একটি প্রস্তর-শীতল ক্লাসিক এক্সওয়াই সমস্যা।

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

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

যখন আপনি ডেটা পেয়েছেন, আপনি কীভাবে সমস্যাটি মোকাবেলা করতে পারেন তা নিয়ে কাজ করতে পারেন এবং তারপরে কোথায় অনুকূলিত করতে পারেন তা নিয়ে কাজ করতে পারেন।


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

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

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

38

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

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


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

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

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

20

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

র‌্যাম সস্তা এবং তাই নিষ্ক্রিয় কোডটি সস্তা। কোড লোড এবং আনলোড হচ্ছে (বিশেষত আনলোড) একটি ভঙ্গুর প্রক্রিয়া এবং আধুনিক ডেস্কটপ / সার্ভার হার্ডওয়্যারটিতে আপনার প্রোগ্রামের কার্যকারিতাটিতে উল্লেখযোগ্য প্রভাব ফেলবে বলে সম্ভাবনা নেই।

ক্যাশে আরও ব্যয়বহুল তবে এটি কেবলমাত্র সক্রিয় কোডগুলিকেই প্রভাবিত করে, এমন কোড নয় যা মেমরিতে অব্যবহৃত রয়েছে।

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

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

এটি ঠিক হওয়া উচিত যতক্ষণ না dlls এবং এক্সিকিউটেবল সমস্ত একই সংকলক দিয়ে নির্মিত হয় এবং একই সি ++ রানটাইম লাইব্রেরির সাথে গতিশীলভাবে সংযুক্ত থাকে। এটি অনুসরণ করে যে যদি অ্যাপ্লিকেশন এবং এর সাথে সম্পর্কিত dlls একক ইউনিট হিসাবে তৈরি এবং স্থাপন করা হয় তবে সমস্যা হওয়া উচিত নয়।

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

আপনি যদি কোনও অ্যাপ্লিকেশন তৈরির বিষয়ে বিবেচনা করছেন, তবে এটি একক পিসি আর হ্যান্ডেল করতে পারে না এমনটি বড় হতে পারে সে সিদ্ধান্তে পৌঁছানো ঠিক কি, এসটিএলকে প্রযুক্তি হিসাবে মোটেও ব্যবহার করা উচিত নয়?

আসলে তা না.

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


2
নিষ্ক্রিয় কোড সম্ভবত র‍্যামে প্রথম স্থানে লোড হয় না। বেশিরভাগ অপারেটিং সিস্টেমগুলি কেবলমাত্র এক্সিকিউটেবলের থেকে পৃষ্ঠাগুলি লোড করে যদি তাদের প্রকৃত প্রয়োজন হয়।
জুলাই

1
@ জুলস: যদি ডেড কোডটি লাইভ কোডের সাথে মিশ্রিত হয় (পৃষ্ঠা-আকার = 4 কে গ্রানুলারিটি সহ), তবে এটি ম্যাপযুক্ত + লোড হবে। ক্যাশে অনেক সূক্ষ্ম (64 বি) গ্রানুলারিটিতে কাজ করে, তাই এটি এখনও বেশিরভাগ ক্ষেত্রেই সত্য যে অব্যবহৃত ফাংশনগুলি খুব বেশি ক্ষতি করে না। যদিও প্রতিটি পৃষ্ঠার একটি টিএলবি এন্ট্রি প্রয়োজন, এবং (র‌্যামের বিপরীতে) যা দুর্লভ রানটাইম সংস্থান। (ফাইল-ব্যাকড ম্যাপিংগুলি সাধারণত ল্যাপটপগুলিতে কমপক্ষে নয়, হ্যাপিপেজ ব্যবহার করে না; এক্সপ্লোর পরিচালনা পৃষ্ঠাগুলি x86-64-তে 2MiB হয়, যাতে আপনি হিটপেজের সাথে কোনও টিএলবি মিস না করে আরও অনেক কোড বা ডেটা কভার করতে পারেন))
পিটার কর্ডস

1
@ পিটারকর্ডস কী দ্রষ্টব্য: সুতরাং, আপনার বিল্ড ফর ফর রিলিজ প্রক্রিয়ার অংশ হিসাবে "পিজিও" ব্যবহার করতে ভুলবেন না!
জেডুগোস্জ 23

13

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

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


7

আপনি এই প্রশ্নের বিন্দু মিস করছেন।

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


5

যদি আপনি একই সংকলকটি একই সময়ে একই উত্স গাছ থেকে ডিএলএলগুলি তৈরি করেন এবং বিকল্পগুলি তৈরি করেন, তবে এটি ঠিক আছে।

তবে বিভাজন প্রণালী একাধিক টুকরা একটি অ্যাপ্লিকেশন "উইন্ডোজ দান" যা কিছু পুনরায় উপভোগ্য এর COM উপাদান । এগুলি ছোট (স্বতন্ত্র নিয়ন্ত্রণ বা কোডেক) বা বৃহত্তর (এমএসটিএমএল.ডিএল-তে একটি সিওএম নিয়ন্ত্রণ হিসাবে পাওয়া যায়) be

প্রয়োজনে ডায়নামিকভাবে লোড করা এবং পরে লোড করা

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

তদতিরিক্ত, যদি আপনার ভার্চুয়াল মেমরি সিস্টেমটি সঠিকভাবে কাজ করে তবে অব্যবহৃত কোড পৃষ্ঠা পৃষ্ঠাভুক্ত করে এটি আপনার পক্ষে এটি পরিচালনা করবে।

এত বড় হতে পারে যে একক পিসি এটিকে আর পরিচালনা করতে পারে না

আরও বড় পিসি কিনুন।

ভুলে যাবেন না যে সঠিক অপ্টিমাইজেশনের মাধ্যমে একটি ল্যাপটপ একটি হ্যাডোপ ক্লাস্টারকে ছাড়িয়ে যেতে পারে।

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


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

3
"একটি বড় পিসি কিনুন" +1। আপনি এখন একাধিক টেরাবাইট র‌্যাম সহ সিস্টেমগুলি অর্জন করতে পারেন । আপনি একা বিকাশকারীর প্রতি ঘন্টার হারের চেয়ে কম অ্যামাজন থেকে ভাড়া নিতে পারেন ire মেমরির ব্যবহার হ্রাস করতে আপনি আপনার কোডটি অনুকূলকরণের জন্য কতটা বিকাশকারী সময় ব্যয় করছেন?
জুলাই

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

সিওএম উপাদান? নব্বইয়ের দশকে হয়তো এখন কিন্তু?
পিটার মর্টেনসেন

@ এসএমএলটারস - ডান ... যে কোনও প্রশ্ন সহ যে কোনও অ্যাপ্লিকেশন একটি পিসিতে কতদূর স্কেল করতে পারে সে সম্পর্কে অ্যামাজন ইসি 2 এক্স 1 ই.32 এক্স্লারজেন্স টাইপ টাইপের জন্য 72 টি স্পেসিফিক প্রসেসর কোর 128 ভার্চুয়াল কোর সরবরাহকারী মেশিনের স্পেসগুলির দিকে নজর দেওয়া উচিত ২.৩ গিগাহার্টজ (৩.১ গিগাহার্টজ-তে বিস্ফুটযোগ্য), সম্ভবত 340 গিগাবাইট / স মেমরি ব্যান্ডউইদথ (কোন ধরণের মেমরি ইনস্টল করা হয়েছে তার উপর নির্ভর করে যা স্পেসে বর্ণিত নয়) এবং র‌্যামের 3.9TiB। মূল র‍্যামটি স্পর্শ না করে বেশিরভাগ অ্যাপ্লিকেশন চালাতে পর্যাপ্ত ক্যাশে রয়েছে। তাও আবার একটা জিপিইউ ছাড়াই এটি 2000 থেকে 500 নোড সুপারকম্পিউটার ক্লাস্টার শক্তিশালী হিসাবে
জুলে

0

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

প্রথম অংশটি বোঝায় (পারফরম্যান্সের কারণে বিভিন্ন মেশিনে বিভক্ত অ্যাপ্লিকেশন)।

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

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

ক্লাসিক সমাধানটি এর মতো দেখাচ্ছে:

[user] [front-end] [machine1] [common resources]
                   [machine2]
                   [machine3]

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

এটি কোনও উপায়েই ডিএলএলগুলির অতিরিক্ত লোডিং / আনলোডিংকে বোঝায় না বা এসটিএল-এর সাথে কোনও সম্পর্ক রাখে না।

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

এটি বলেছে, আপনার সরবরাহিত সীমিত তথ্যের সাথে এটি ক্লাসিক এক্স সমস্যা মতো দেখাচ্ছে (যেমন @ গ্রাহাম বলেছেন) said

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