Visual Studio - تأثير وقت التشغيل لنقاط التوقف الشرطية والمعوقة

Question

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

أفترض أن نقطة التوقف في مسار الكود الذي لم يتم تنفيذه ليس له أي تأثير في وقت التشغيل.

لذا فإن سؤالي ذو شقين:

1. هل هناك أي موارد يمكن أن تحدد التكلفة المرتبطة بنقاط التوقف الشرطية ، وإذا كان الأمر كذلك ، فهل هناك أي شيء يمكن للمرء أن يفعله لتقليل تكلفة تقييم وقت التشغيل؟
2. هل هناك أي تكلفة مرتبطة بنقطة توقف "معطلة"؟ من خلال تعطيل ، أعني أن VS يعرض علامة نقطة التوقف في الحضيض مع دائرة مجوفة.

بالطبع إذا كان أي شيء ذكرته أعلاه لا معنى له ، فالرجاء توجيهني في الاتجاه الصحيح.

Answer 1

من الصعب تحديد تكلفة نقطة توقف مشروطة. يتم تقييم التعبير في نقطة توقف مشروطة باستخدام نفس الدلالات بالضبط كما لو كنت قد كتبته في الساعة أو النافذة الفورية. لا يتم تنفيذ التعبيرات عن هذا الطبيعة بالفعل في برنامج العميل ولكن بدلاً من ذلك يتم التعامل معها بواسطة تقييم تعبير اللغة المحددة. ليس من الممكن حقًا تحديد هذه الأنواع من التقييمات بطريقة هادفة.

ومع ذلك ، يمكنني إدراج بعض الأشياء المعروفة بأنها أبطأ في تقييم نافذة التصحيح

• مكالمات الوظائف: إنها أبطأ شيء يمكنك القيام به لأن استدعاء الوظيفة تتطلب إعادة تشغيل عملية التصحيح
• مقارنة السلسلة: تحت غطاء محرك السيارة ، تعود إلى Func Evals

أما بالنسبة لنقاط التوقف المعاق ، فلا تؤثر على تشغيل التطبيق.

Answer 2

شيء واحد يجب الانتباه إليه (الذي تعلمته بالطريقة الصعبة) هو التأكد من وضعك == عند مقارنة متغير بالقيمة وليس العازبة =

محرر نقطة التوقف لا يحذرك ولكن عندما يتم تقييم نقطة التوقف ، يتم تغيير المتغير! استغرق مني بعض الوقت لتصحيح رمزتي مع هذا واحد!

أيضًا ، إذا كنت بحاجة حقًا إلى نقطة التوقف الشرطية إلى رمز bebug ؛ أقوم بإضافة الشرط إلى الكود ، ثم أضف شيئًا مثل String STOP = "هنا" ؛ ووضع نقطة توقف طبيعية هناك - أجد أن الكود يعمل بشكل أسرع بعد ذلك.

Answer 3

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

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

Answer 4

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

ما أفعله عندما أكون في موقف مثلك هو جعل ماكرو التأكيد. (يمكنك استخدام ال يجزم الماكرو الذي يوفره Visual Studio ، لكني لا أحب ذلك). اجعل الماكرو الخاص بك تحقق من الشرط الذي تريده ثم اتصل تصحيح الأخطاء إذا فشلت. في الواقع ، أو البناء غير المحدد لتطبيقك ، تأكدوا على تقييم لا شيء ، لذلك لا يتأثر الكود الخاص بك.

يمكن أن يبدو ماكرو تأكيد بسيط:

#ifdef _DEBUG
#define assert(x)\
do{\
  if(!(x)){DebugBreak();}\
}while(0)
#else
#define assert(x)
#endif

ويسميها مثل:

assert(pValue != NULL && "A bad parameter was passed to the function");

يمكنك وضع المزيد من التعليمات البرمجية في الفشل قبل التصحيح (مثل طباعة الحالة التي فشلت مع #X ، و/أو رقم السطر/الملف مع ____file____ و ____line__ حتى يمكنك النقر المزدوج على الرسالة). يمكنك كتابة رسائل إلى سجل التصحيح مع outputDebugString وحتى تحقق لمعرفة ما إذا كان مصحح الأخطاء متصلة مع isDebuggerPresent لتخصيص تأكيدك أكثر. أود أيضًا استخدام تنسيق String && لإعطاء المزيد من المعلومات حول التأكيد المعين.

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

Answer 5

1. حاول وضع نقطة التوقف في الكود لاختبار الأداء. على سبيل المثال

   Stopwatch st = new Stopwatch();
   st.Start();
   if(my condition)
   {
     st.Stop();
     Debugger.Break();
   }
   

   لا ، ليس بالضبط نفس الشيء ولكنه قريب بما فيه الكفاية.

2. لا - نقطة توقف معاق غير موجودة في برنامج التنفيذ. يتم تخزينه للتو في بيانات التعريف VS لراحتك.