জিসি.কলেক্ট () ব্যবহার সম্পর্কে এত ভুল কী?


103

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

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

প্রশ্ন: এই ক্ষেত্রে, দ্বিতীয় পর্যায়ে প্রবেশের আগে জিসি.কোলেক্ট () কল করা কি বুদ্ধিমানের কাজ হবে না?

সর্বোপরি, এই দুটি পর্যায় কখনই একে অপরের সাথে ওভারল্যাপ হয় না এবং জিসি যে সমস্ত অপ্টিমাইজেশন এবং পরিসংখ্যান সংগ্রহ করতে পারত তা এখানে খুব কম কাজে লাগবে ...

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

ধন্যবাদ।


24
"প্রোগ্রামের প্রবাহে সামান্যতম পরিবর্তন বিপর্যয়কর পরিণতি আনতে পারে ... কেউ মারা যেতে পারে" - আপনি কি নিশ্চিত সি #। নেট আপনার প্রয়োজনের জন্য যথেষ্ট পরিমাণে নির্বিচারে?
স্টিভ জেসোপ

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

3
LOL এ "এইগুলির মধ্যে একটি জিনিস যা সম্মানজনক প্রোগ্রামাররা কখনই ব্যবহার করবে না, এমনকি যারা জানেন না এটি কীসের জন্য"! প্রোগ্রামাররা যারা স্টাফ ব্যবহার করেন তারা জানেন না কেন আমার বইতে খুব সম্ভবত শ্রদ্ধেয়। :)
দাগ

উত্তর:


87

রিকার ব্লগ থেকে ...

বিধি # 1

না।

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

বিধি # 2

জিসি.কলেক্ট () কল করার বিষয়টি বিবেচনা করুন যদি কিছু অ-পুনরাবৃত্ত ইভেন্ট ঘটে থাকে এবং এই ইভেন্টটি সম্ভবত অনেকগুলি পুরানো বস্তু মারা যাওয়ার সম্ভাবনা রয়েছে।

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

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

দৃ #় প্রমাণ ছাড়াই # 1 বিধি নিয়মের # 2 ট্রাম্প করা উচিত।

পরিমাপ, পরিমাপ, পরিমাপ।


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


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

58

আপনি যদি প্রোডাকশন কোডে জিসি.কলেক্ট () কল করেন তবে আপনি অবশ্যই জিসির লেখকগণ যে আরও জানেন তা ঘোষণা করছেন। যে ক্ষেত্রে হতে পারে। তবে এটি সাধারণত হয় না, এবং তাই দৃ strongly়ভাবে নিরুৎসাহিত হয়।


3
এটি খুব সত্য, তবে আমি জানি না যে তারা এমন ধারনা তৈরি করতে পারে যা সমস্ত বিকাশের জন্য প্রযোজ্য।
মাস্টারমাস্টিক

2
@ কেন না, তারা পারবে না। তবে আপনি কি আরও ভাল অবস্থানে আছেন? অথবা আপনি নির্দিষ্ট হার্ডওয়্যার, একটি নির্দিষ্ট ওএস সংস্করণ এবং আরও ধরে ধরে কোড লিখতে যাচ্ছেন? ব্যথা / লাভের অনুপাতটি এর চেয়ে খুব বেশি।
দাগ

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

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

24

সুতরাং আপনি যখন .NET থেকে এমএস ওয়ার্ড বা এমএস এক্সেলের মতো COM অবজেক্ট ব্যবহার করছেন তখন কীভাবে? GC.CollectCOM অবজেক্টগুলি প্রকাশের পরে কল না করে আমরা দেখতে পেয়েছি যে ওয়ার্ড বা এক্সেল অ্যাপ্লিকেশন উদাহরণগুলি এখনও বিদ্যমান।

আসলে আমরা যে কোডটি ব্যবহার করি তা হ'ল:

Utils.ReleaseCOMObject(objExcel)

' Call the Garbage Collector twice. The GC needs to be called twice in order to get the
' Finalizers called - the first time in, it simply makes a list of what is to be finalized,
' the second time in, it actually does the finalizing. Only then will the object do its 
' automatic ReleaseComObject. Note: Calling the GC is a time-consuming process, 
' but one that may be necessary when automating Excel because it is the only way to 
' release all the Excel COM objects referenced indirectly.
' Ref: http://www.informit.com/articles/article.aspx?p=1346865&seqNum=5
' Ref: http://support.microsoft.com/default.aspx?scid=KB;EN-US;q317109
GC.Collect()
GC.WaitForPendingFinalizers()
GC.Collect()
GC.WaitForPendingFinalizers()

তাহলে তা কি আবর্জনা সংগ্রহকারীদের ভুল ব্যবহার হবে? যদি তা হয় তবে আমরা কীভাবে ইন্টারপ অবজেক্টগুলি মরতে পারি? এছাড়াও যদি এটি এর ব্যবহারের জন্য বোঝানো না হয় তবে GCএর Collectপদ্ধতিটি কেন Public?


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

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

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

15

ঠিক আছে, জিসি সেগুলির মধ্যে আমার একটি প্রেম / ঘৃণার সম্পর্ক। আমরা অতীতে ভিস্তাডিবির মাধ্যমে এটি ভেঙে ফেলেছি এবং এটি সম্পর্কে ব্লগ করেছি। তারা এটি স্থির করেছে, তবে এগুলির মতো জিনিসগুলির থেকে ফিক্সগুলি পেতে খুব দীর্ঘ সময় লাগে।

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

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

আপনি সিরিজ খারাপ GC.Collectবিবৃতি দিয়ে পুরো মেশিন স্ক্রু করতে পারেন । সংগ্রহের বিবৃতি প্রয়োজন প্রায়শই সর্বদা বৃহত্তর অন্তর্নিহিত ত্রুটির দিকে নির্দেশ করে। মেমরি ফাঁস সাধারণত উল্লেখ এবং তারা কীভাবে কাজ করে তা বোঝার অভাবের সাথে কাজ করে। অথবা IDisposableযে জিনিসগুলিতে এটির প্রয়োজন হয় না সেগুলি ব্যবহার করে এবং জিসির উপর অনেক বেশি লোড চাপায়।

সিস্টেম পারফরম্যান্স কাউন্টারগুলির মাধ্যমে জিসিতে ব্যয় করা সময়ের% ঘনিষ্ঠভাবে দেখুন। আপনি যদি আপনার অ্যাপ্লিকেশনটিকে জিসিতে 20% বা তার বেশি সময় ব্যবহার করে দেখেন আপনার গুরুতর অবজেক্ট ম্যানেজমেন্ট সমস্যা (বা একটি অস্বাভাবিক ব্যবহারের ধরণ) রয়েছে। আপনি জিসি ব্যয় করার সময়টি সর্বদা হ্রাস করতে চান কারণ এটি আপনার পুরো অ্যাপ্লিকেশনটিকে ত্বরান্বিত করবে।

জিসি ওয়ার্কস্টেশনগুলির চেয়ে সার্ভারে আলাদা is আমি লোকেরা উভয়কেই পরীক্ষা না করায় সমস্যাগুলি নিরূপণ করতে বেশ কয়েকটি ছোট সমস্যা দেখেছি (বা এমনকি তারা সচেতন নয় যে তাদের মধ্যে দুটি)।

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


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

5
কীভাবে একজন পুরো মেশিনটিকে স্ক্রু আপ করতে পারেন?
অ্যাডাম আর গ্রে 15

13

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


12

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


10

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

অবশ্যই, আপনি এটি প্রোফাইল করা উচিত, এবং নিজের জন্য দেখুন।


9

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

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


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

7

রেফারেন্স চেক করে প্রতিটি বস্তু সত্যই প্রকাশ করা যেতে পারে কিনা তা দেখতে জিসি.ক্লোকটকে () কল করা সিএলআরকে স্ট্যাক ওয়াক করতে বাধ্য করে। বস্তুর সংখ্যা বেশি হলে এটি স্কেলাবিলিটিটিকে প্রভাবিত করবে এবং জঞ্জাল সংগ্রহকে প্রায়শই ট্রিগার করতেও পরিচিত। সিএলআরকে বিশ্বাস করুন এবং উপযুক্ত হয়ে উঠলে আবর্জনা সংগ্রহকারীকে নিজেই চালাবেন।


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

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

6

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

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

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

এর পরে, আমি মনে করি এটি ভালভাবে কাজ করছে, কমপক্ষে কোনও ব্যতিক্রম নেই !!!
আমি নিম্নলিখিত উপায়ে কল:

var obj = /* object utilizing the memory, in my case Form itself */
GC.Collect(GC.GetGeneration(obj ,GCCollectionMode.Optimized).

5

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

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

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


5

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

একেবারে সময় আছে যে আপনাকে জিসি.ক্ল্যাক্ট কল করতে হবে।


2
কলিং Disposeহয় কথা না পরিচালিত মেমরির ছেড়ে দিন। .NET- এ মেমরি মডেল কীভাবে কাজ করে তা আপনি জানেন না।
অ্যান্ড্রু বারবার

4

আবর্জনা সংগ্রহকারী আবর্জনা সংগ্রহ না করে এবং মেমরি মুক্ত করে না আমাদের এই জাতীয় সমস্যা ছিল।

আমাদের প্রোগ্রামে, আমরা ওপেনএক্সএমএল সহ কিছু পরিমিত আকারের এক্সেল স্প্রেডশিটগুলি প্রক্রিয়াজাত করছি। স্প্রেডশীটগুলিতে 14 টি কলামের প্রায় 1000 সারি সহ 5 থেকে 10 "শীট" পর্যন্ত যে কোনও জায়গায় রয়েছে।

32 বিট পরিবেশে (x86) প্রোগ্রামটি "মেমরির বাইরে" ত্রুটির সাথে ক্র্যাশ হয়ে যায়। আমরা এটি একটি x 64 পরিবেশে চালানোর জন্য পেয়েছি, তবে আমরা আরও ভাল সমাধান চাইছি।

আমরা একটি পেয়েছি।

সুস্পষ্টভাবে নিষ্পত্তিযোগ্য বস্তুগুলি থেকে স্মৃতি মুক্ত করার জন্য আবর্জনা সংগ্রাহককে কল করার সময় কী কাজ করে না এবং কী কাজ করে তার কিছু সরল কোড কোড রয়েছে।

সাবরুটিনের ভিতরে থেকে জিসিকে কল করা কার্যকর হয়নি। স্মৃতি কখনও পুনরুদ্ধার করা হয়নি ...

For Each Sheet in Spreadsheets
    ProcessSheet(FileName,sheet)
Next

Private Sub ProcessSheet(ByVal Filename as string, ByVal Sheet as string)
    ' open the spreadsheet 
    Using SLDoc as SLDocument = New SLDocument(Filename, Sheet)
        ' do some work....
        SLDoc.Save
    End Using
    GC.Collect()
    GC.WaitForPendingFinalizers()
    GC.Collect()
    GC.WaitForPendingFinalizers()
End Sub

সাবসিটিনের আওতার বাইরে জিসি কলটি সরিয়ে, আবর্জনা সংগ্রহ করা হয়েছিল এবং স্মৃতিটি মুক্ত হয়েছিল।

For Each Sheet in Spreadsheets
    ProcessSheet(FileName,sheet)
    GC.Collect()
    GC.WaitForPendingFinalizers()
    GC.Collect()
    GC.WaitForPendingFinalizers()
Next

Private Sub ProcessSheet(ByVal Filename as string, ByVal Sheet as string)
    ' open the spreadsheet 
    Using SLDoc as SLDocument = New SLDocument(Filename, Sheet)
        ' do some work....
        SLDoc.Save
    End Using
End Sub

আমি আশা করি যে এটি কলগুলিকে উপেক্ষা করার সময় NET আবর্জনা সংগ্রহে হতাশ হয়ে অন্যদের সহায়তা করে GC.Collect()

পল স্মিথ


4

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

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

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

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


2

আমি মনে করি আপনি দৃশ্যের বিষয়ে সঠিক, তবে আমি এপিআই সম্পর্কে নিশ্চিত নই।

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


2
আকর্ষণীয়, তবে ডকুমেন্টেশন বলছে যে 'যখন একটি ছোট পরিচালিত অবজেক্ট প্রচুর পরিমাণে পরিচালনা না করা মেমরির বরাদ্দ দেয়' তখন অ্যাডমেমোরিপ্রেস ব্যবহার করা উচিত। (জোর আমার)
রবার্ট পলসন

2

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


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

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

2

জিসি.কলেক্ট () কল করার আকাঙ্ক্ষা সাধারণত আপনি অন্য কোথাও যে ভুল করেছেন সেগুলি coverাকানোর চেষ্টা করছে!

আপনার যদি প্রয়োজন হয় না এমন জিনিসগুলি নিষ্পত্তি করতে আপনি কোথায় ভুলে গেছেন তা যদি ভাল হয়।


5
সম্ভবত একটি সাধারণীকরণ শুরু হয়েছে
মিকিডি

1

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


1

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


তিনি। নেট মাইক্রো ফ্রেমওয়ার্ক ব্যবহার করতে পারেন, যা রিয়েল-টাইম পরিবেশের জন্য ডিজাইন করা হয়েছিল।
ট্রমাপনি

@TraumaPony: এই পৃষ্ঠার নীচের অংশে অবস্থিত চার্ট চেক করুন msdn.microsoft.com/en-us/embedded/bb278106.aspx স্পষ্টত মাইক্রো ফ্রেমওয়ার্ক রিয়েল-টাইম পরিবেশের জন্য বানানো হয়নি। এটি এমবেডড পরিবেশের জন্য তৈরি করা হয়েছিল (উইনসিসির মতো) তবে কম বিদ্যুতের প্রয়োজনীয়তার সাথে।
স্কট ডোরম্যান

1

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

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

উভয় ক্ষেত্রেই ফলাফলটি সহজ ছিল: কোনও জিসি.কলেক্ট, মেমরির বাইরে নয়, ধারাবাহিকভাবে; জিসি.কোলেক্ট, ত্রুটিহীন কর্মক্ষমতা।

আমি চেষ্টা করেছি মেমরির সমস্যাগুলি সমাধান করার জন্য আরও কয়েকবার, কোনও লাভ হয়নি। আমি এটি বের করে নিলাম।

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

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

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