متى تتخلى عن تجزئة الكومة المدارة

Question

كنت أقرأ أ إدخال المدونة بقلم جوش سميث حيث استخدم آلية ذاكرة التخزين المؤقت من أجل "تقليل تجزئة الكومة المدارة". يقلل التخزين المؤقت له من عدد الكائنات قصيرة الأجل التي يتم إنشاؤها على حساب سرعة التنفيذ أبطأ قليلاً.

ما مقدار المشكلة التي تتم إدارتها تجزئة الكومة بلغة مُدارة مثل C#؟ كيف يمكنك تشخيص ما إذا كانت مشكلة؟ في أي حالات ستحتاج عادة إلى معالجتها؟

Answer 1

متى

ليس بسرعة كبيرة. من الرخيصة عمومًا أن يكون لديك أشياء قصيرة العمر. لكي تكون ذاكرة التخزين المؤقت مربحة ، يجب أن يكون هناك (جدًا) العديد من Candiadates ويجب أن يعيشوا لفترة كافية للوصول إلى الجيل القادم.

كيف يمكنك تشخيص ما إذا كانت مشكلة؟

مع profiler. لست متأكدًا من أن مؤلف المقال فعل ذلك.

ما مقدار المشكلة التي تتم إدارتها تجزئة الكومة بلغة مُدارة مثل C#؟

بقدر ما أعرف أنه نادر. .NET لديه جامع القمامة المضغوط ، الذي يمنع معظم أشكال التجزئة. هناك مشاكل مع كومة الكائن الكبيرة في بعض الأحيان.

---

تعديل:

عندما تمر بالتعليقات أدناه ، ستجد أن شخصًا ما قام بقياسه ووجدت أن ذاكرة التخزين المؤقت أبطأ بكثير من إنشاء EventArgs جديدة في كل مرة.

خاتمة: قياس قبل البدء في التحسين. لم تكن هذه فكرة جيدة/مثال.

Answer 2

ما لم تكن تتعامل مع كائنات صغيرة قصيرة الأجل 10K+ قصيرة الأجل في الثانية ، فلا ينبغي أن تكون مشكلة على الإطلاق على جهاز كمبيوتر حديث مع كمية معقولة من ذاكرة الوصول العشوائي.

لذا ، يجب عليك أولاً تشغيل الكود في جميع السيناريوهات المعقولة وإذا كان سريعًا بما فيه الكفاية - فلا تقلق بشأنه.

إذا لم تكن راضيًا عن السرعة ، فسترى هذا الرمز في وقت ما "الاختناق" أو مجرد فضول ، يمكنك مراقبة مختلف إحصائيات ذاكرة .NET (http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx) في تطبيق مراقبة الأداء (يأتي كجزء من Windows). على وجه التحديد أنت مهتم بنسبة ٪ في GC.

Redgate Ants Profiler يراقب أيضا هذه الإحصائيات.

Answer 3

عادة ما يكون تجزئة الكومة المدارة بسبب تثبيت الكائنات. يتم تثبيت الكائنات عند نقل الرمز المدارة مؤشر الكائن إلى الكود الأصلي ولا يمكن نقل الكائن لأنه يتم تمرير المرجع إلى الكود الأصلي. هذا أمر شائع جدًا عندما يكون هناك الكثير من أنشطة الإدخال/الإخراج. كما ذكر أعلاه ، عادة ما يحدث فقط في LOH.

هنا مثال على التفتت في Gen0 Heap

Answer 4

على عكس الإجابات الأخرى المقدمة هنا ، فأنا: نعم ، يجب على المرء أن يعتني بالتفتت! لا ينطبق فقط على أكوام المدارة ولكن على جميع التطبيقات المعالجة (على الأقل)

• العديد من "الكبير" في
• نمط تخصيص ثقيل.

نظرًا لأن LOB لا يتم ضغطه ، فإنه - مع مرور الوقت - على الأرجح سوف يتم تجزئه بمجرد أن يتجاوز حجم وعدد الكائنات قيمة معينة (تتعلق بالمواطن الكلية المتاحة). إذا كان الأمر كذلك ، فإن الطريقة الآمنة الوحيدة هي الحد من عدد الإشارات المعلقة على الفور إلى تلك الكائنات. ستساعد ذاكرة التخزين المؤقت (تجمع) فقط ، إذا كان يمكن إعادة استخدام الكائنات المجمعة. في بعض الأحيان ، إذا كانت هذه ressources مصنوعة من صفائف ذات طول متفاوتة ، فقد لا يمكن إعادة استخدامها بسهولة. لذلك قد لا يساعد التجميع كثيرًا هنا.

كيف تكتشف ذلك؟ عندما يكون هناك ضغط كبير على كومة LOB. كيف تكتشف ذلك؟ استخدم .NET Performance Counter "Collection Count Gen 0 ... 2" في نفس الوقت. إذا تم تخصيص عدد كبير جدًا من الكائنات الكبيرة من LOB ، فستتطور جميع العدادات بشكل مماثل. بمعنى ، في الأساس جميع المجموعات مكلفة الجيل 2 مجموعات. في هذه الحالة ، يجب القيام بشيء ما.

فيما يتعلق بالأشياء الأصغر ، أود أن أترك GC يقوم بكل العمل في مجموعات Gen 0 ولا تقلق.