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

CharliePoole هذه نقطة جيدة ، لكنني

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users\Developer>cd /D D:\code

D:\code>NUnit.ConsoleRunner.3.6.1\tools\nunit3-console.exe D:\code\test\Web\bin\Tests.dll
NUnit Console Runner 3.6.1
Copyright (C) 2017 Charlie Poole

Runtime Environment
   OS Version: Microsoft Windows NT 6.3.9600.0
  CLR Version: 4.0.30319.42000

Test Files
    D:\code\test\Web\bin\Tests.dll


Run Settings
    DisposeRunners: True
    WorkDirectory: D:\code
    ImageRuntimeVersion: 4.0.30319
    ImageTargetFrameworkName: .NETFramework,Version=v4.6.1
    ImageRequiresX86: False
    ImageRequiresDefaultAppDomainAssemblyResolver: False
    NumberOfTestWorkers: 8

Test Run Summary
  Overall result: Passed
  Test Count: 175, Passed: 175, Failed: 0, Warnings: 0, Inconclusive: 0, Skipped: 0
  Start time: 2017-06-04 20:37:00Z
    End time: 2017-06-04 20:37:07Z
    Duration: 7.195 seconds

Results (nunit3) saved as TestResult.xml

D:\code>NUnit.ConsoleRunner.3.6.1\tools\nunit3-console.exe D:\code\test\Web\bin\Tests.dll
NUnit Console Runner 3.6.1
Copyright (C) 2017 Charlie Poole

Runtime Environment
   OS Version: Microsoft Windows NT 6.3.9600.0
  CLR Version: 4.0.30319.42000

Test Files
    D:\code\test\Web\bin\Tests.dll


Run Settings
    DisposeRunners: True
    WorkDirectory: D:\code
    ImageRuntimeVersion: 4.0.30319
    ImageTargetFrameworkName: .NETFramework,Version=v4.6.1
    ImageRequiresX86: False
    ImageRequiresDefaultAppDomainAssemblyResolver: False
    NumberOfTestWorkers: 8

Test Run Summary
  Overall result: Passed
  Test Count: 175, Passed: 175, Failed: 0, Warnings: 0, Inconclusive: 0, Skipped: 0
  Start time: 2017-06-04 20:38:17Z
    End time: 2017-06-04 20:38:20Z
    Duration: 2.540 seconds

Results (nunit3) saved as TestResult.xml

D:\code>

كانت الجولة الأولى (حوالي 7 ثوانٍ) مع إغلاق VS ، والثانية (~ 2 ثانية) كانت مفتوحة.

مثير للاهتمام. بصفتنا مطورين ، نجري دائمًا اختبارات NUnit محليًا مع تشغيل VS ، لذا فهذه هي الأوقات التي نراها. سأقوم ببعض التجارب.

بصفتنا مطورين ، نجري دائمًا اختبارات NUnit محليًا مع تشغيل VS ، لذا فهذه هي الأوقات التي نراها.

هذا بالضبط ما وجدناه ، فقط على CI لاحظنا فرق وقت التشغيل في البداية.

لا يمكنني تكرار هذا ، لذا أقوم بوضع علامة عليه لشخص آخر لمحاولة التأكيد.

عندما أجريت تجاربك ، هل جربتها مع VS مفتوحًا ولكن لم يتم تحميل أي حل؟ أتساءل عما إذا كان يمكن أن يكون له علاقة ببعض التجمعات الموجودة في الذاكرة بالفعل.

أفترض أنه لا اختباراتك ولا SUT الخاص بك يستخدم VS بأي شكل من الأشكال - أي أنك لا تقوم بتحميل نموذج كائن VS أو أي شيء من هذا القبيل.

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

أنا أعمل على Windows 10.

mintsoft مجرد تخمين ، ولكن هل يمكنك تكرار الاختبار مع تشغيل برنامج .NET آخر ، حتى لو تم حظر تطبيق وحدة تحكم بسيط في Console.Readline() ؟ إنه امتداد ، لكنني أشعر بالفضول إذا لم يكن له علاقة ببرنامج Visual Studio ، ولكن بدلاً من ذلك حقيقة أن برنامج .NET قيد التشغيل وبالتالي فإن CLR موجود في الذاكرة.

أيضًا ، هل أنت قادر فقط على إعادة إنتاج هذا على جهاز CI الخاص بك أم أنك تقوم أيضًا بإعادة إنتاجه على أجهزة التطوير الخاصة بك؟

rprouse لقد جربت ذلك للتو ، تم إجراء الاختبارات في حوالي 9 ثوانٍ (هذا هو الوقت البطيء) مع تشغيل تطبيق وحدة التحكم في الخلفية.

يمكنني إعادة إنتاج هذا على أجهزة التطوير بسهولة كافية حتى مع تثبيت جديد لنظام التشغيل windows.

لقد جربت تطبيقات أخرى مفتوحة ، ومن المثير للاهتمام أنها لا تبدو مقصورة على Visual Studio. أحد التطبيقات التي كانت مثيرة للاهتمام بشكل خاص هو تطبيق ModernUI WPF Example (https://github.com/firstfloorsoftware/mui/tree/master/1.0/FirstFloor.ModernUI/FirstFloor.ModernUI.App). قمت بتجميعها وتشغيلها ووجدت أنه إذا كانت قيد التشغيل عند تنفيذ الاختبارات ، فإنها تعمل مرة أخرى في حوالي 2.5 / 3 ثانية (سرعة عالية). أغلقه ، وقم بإجراء الاختبارات مرة أخرى وسأعود إلى 8 ثوانٍ. أنا حائرة جدا الآن

ربما نحن ننظر إلى هذا الخطأ. هل يمكن أن تكون المشكلة في كيفية الإبلاغ عن الوقت؟

ربما نحن ننظر إلى هذا الخطأ. هل يمكن أن تكون المشكلة في كيفية الإبلاغ عن الوقت؟

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

لقد قمت بعمل صورة gif سريعة تظهره:

لا يوجد شيء آخر مفتوح على الإطلاق بخلاف ShareX و cmd و nunit-console.

هناك 3 عمليات تشغيل بطيئة (8-9 ثوانٍ) ، ثم أقوم بفتح تطبيق ModernUI الذي جمعته (استنادًا إلى التطبيق المرتبط سابقًا ، ولكن مع حذف الأشياء منه) ، انخفض الأمر إلى أقل من 3 ثوانٍ. أغلقت تطبيق ModernUI مرة أخرى ، وعاد إلى 8-9 ثوانٍ.

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

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

عذرًا ، أنا مخطئ ، يتم إخراج إعدادات التشغيل في نهاية التشغيل التجريبي. لا يزال من الممكن أن يكون مرتبطًا بالوكيل البعيد ، لذا يرجى محاولة التبديل --inprocess وإخباري بالنتائج.

rprouse لقد اختبرت أنه على أي حال ، فإن --inprocess ليس له أي تأثير على أي من الوقت. لا يزال ~ 3 ثوان مقابل 8 ثوان.

هذا متوقع نظرًا لأن التوقيت يتم بالكامل داخل رمز الإطار.

CharliePoole لقد تمكنت من إعادة إنتاجه على جهاز الكمبيوتر المحمول الذي يعمل بنظام Windows 10 Pro بنفس السلوك بشكل أساسي. 11 ثانية عادية ، 3 مع فتح تطبيق ModernUI. لذلك لا يبدو أنه يقتصر على Windows Server 2012 R2

لقد قمت أيضًا بإعادة إنتاجه على جهاز سطح المكتب الشخصي الخاص بي الذي يعمل بنظام Windows 10 Pro ، على الرغم من أنني اضطررت إلى إعادة التشغيل من أجل الحصول على الوقت "البطيء" ، ثم حصلت على نفس السلوك مثل 2012 R2 وجهاز الكمبيوتر المحمول الخاص بي.
كما أن جهاز الكمبيوتر المحمول القديم الذي يعمل بنظام Windows 7 لديه نفس السلوك

تحية للجميع،

يمكنني إعادة إنتاج هذا السلوك. مع تطبيق ModernUI Application _closed_ ، تستغرق الاختبارات حوالي 10-11 ثانية حتى تكتمل. مع _ open_ الاختبارات تستغرق حوالي 3-4 ثوانٍ.

يمكن العثور على اختباراتي هنا . لقد أرفقت الإخراج المطول للتشغيل البطيء والسريع.

slow.txt
fast.txt

تحرير * النتائج أعلاه مأخوذة من كمبيوتر سطح المكتب الخاص بي الذي يعمل بنظام التشغيل Windows 10 v1703. لقد قمت بتنفيذ نفس السيناريو بالضبط على جهاز Surface Pro 3 (الذي يعمل بنظام التشغيل Windows 8.1). ولدي نفس السلوك.

سريع-Surface.txt
بطيء السطح. txt

هتافات،
إندي

@ Singh400 هل لديك ملفات xml الإخراج من التشغيل؟

mintsoft هذه من جهاز كمبيوتر سطح المكتب الخاص بي الذي يعمل بنظام التشغيل Windows 10 v1703: -

Slow_TestResult.txt
Fast_TestResult.txt

هتافات،
إندي

شكرا ، إنه ممتع. بالنظر إلى بعض الاختبارات ، لا يبدو أن هناك أي شيء واضح باستثناء أن الفترات أطول على المدى البطيء لجميع الاختبارات: / غريب

mintsoft أحصل على نفس السلوك إذا استخدمت AnimationExamples بدلاً من تطبيق ModernUI.

هل يمكنك تأكيد؟

هتافات،
إندي

وجدت أفضل مثال ؛ الرسوم المتحركة

1. بناء الرسوم المتحركة افتح وأبق ملف exe. مفتوحًا.

2. قم بتشغيل مجموعة الاختبار. تنفيذ الاختبار بطيء.

3. في AnimationTiming ، انقر فوق "بدء الرسوم المتحركة" ضمن علامة التبويب "مثال تكرار السلوك"

4. قم بتشغيل مجموعة الاختبار. تنفيذ الاختبار سريع.

5. في AnimationTiming ، انقر فوق "إيقاف" ضمن علامة التبويب "مثال تكرار السلوك"

6. قم بتشغيل مجموعة الاختبار. تنفيذ الاختبار بطيء.

هل يمكن لأي شخص آخر أن يؤكد؟

@ Singh400 نعم أستطيع أن أؤكد أن هذا هو بالضبط ما أراه. لم يتم تجميع نصف هذه الأمثلة بالنسبة لي ، ولكن AnimationTiming يتصرف تمامًا كما ذكرت.

هذا أمر غريب حقًا ، يبدو أن الرسوم المتحركة لـ WPF تجبر الإطار على نوع من وضع التوقيت عالي الدقة الذي يؤثر على الطريقة التي يقوم بها عداء وحدة التحكم NUnit بجدولة تنفيذ الاختبار؟

mintsoft لأكون صادقًا ، ليس لدي أي فكرة. أعتقد أنه متعلق بـ GPU / GFX _انظر تحرير_. لعبت للتو مع إيقاف / بدء هذا الفيديو . لقد اخترت في البداية 8K على أمل أن تجعل الاختبارات سريعة. لم تفعل. تم اختيار 144 بكسل ، وأرى أن بطيئًا / سريعًا يتصرف عندما أوقف / أبدأ الفيديو. لقد قمت بتضمين الفيديو في ملف html بسيط للتأكد من عدم وجود أي تأثير آخر.

أعتقد أن ما يحدث هو أن تطبيقات WPFs تلمح / تستدعي GPU _ انظر تحرير _ وكذلك تشغيل مقاطع الفيديو في Chrome. ومن ثم فإن هذا له تأثير جانبي في NUnit لجعل الاختبارات تسير بسرعة. إن معرفتي فيما وراء هذه النقطة سطحية للغاية ، لذا لا يمكنني إلا أن أخمن وأبدأ في وضع افتراضات.

_ * تحرير: _ Chrome ، WPF إجراء تغييرات على دقة مؤقت windows. الثلاث وظائف التالية تحتوي على مزيد من المعلومات.

أعتقد أن ما يحدث هو أن تطبيقات WPFs تلمح / تستدعي وحدة معالجة الرسومات مثل تشغيل مقاطع الفيديو في Chrome. ومن ثم فإن هذا له تأثير جانبي في NUnit لجعل الاختبارات تسير بسرعة. إن معرفتي فيما وراء هذه النقطة سطحية للغاية ، لذا لا يمكنني إلا أن أخمن وأبدأ في وضع افتراضات.

حسنًا ، كل هذا يبدو وكأنه تخمين ، لكنني كنت أبحث في كيفية قيام NUnit بجدولة الاختبار:
https://github.com/nunit/nunit-console/blob/master/src/NUnitEngine/nunit.engine/Runners/AggregatingTestRunner.cs#L160

لا أستطيع أن أرى في أي مكان أن LevelOfParallelism قد تم تعيينه فعليًا على أي شيء آخر غير 1.

قد تكون أصوات مثل هذه مرتبطة بالتغييرات في دقة مؤقت النوافذ.

@ appel1 لذلك وجدت هذه المدونة . باستخدام الأداة المساعدة ClockRes ، تمكنت من تأكيد تغيير في "فاصل المؤقت الحالي" عند بدء الرسوم المتحركة وإيقافها في AnimationTiming. الذي يتطابق مع السلوك السريع والبطيء. لقد تحققت أيضًا عند مشاهدة مقطع فيديو في Chrome ، نفس التغييرات على الفاصل الزمني للمؤقت.

@ Singh400 @ appel1 هذا هو بالضبط ما هو عليه.

إذا تركت هذا يعمل في الخلفية ، فسأحصل على ميزة الأداء:

using System;
using System.Runtime.InteropServices;

namespace MakeTestRunsFastAgain
{
    class Program
    {
        static void Main()
        {
            int x;
            var desiredIntervalIn100nsUnits = 5;
            NtSetTimerResolution(desiredIntervalIn100nsUnits, true, out x);
            Console.ReadLine();
        }

        [DllImport("ntdll.dll", SetLastError = true)]
        static extern int NtSetTimerResolution(int DesiredResolution, bool SetResolution, out int CurrentResolution);
    }
}

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

كما ذكرنا سابقًا ، لا أعتقد أن الأداء يتغير

CharliePoole أعتقد أن الأمر يعتمد على كيفية تعريفك لها. لا يعني ذلك أن مدة الإخراج في التقرير خاطئة. تستغرق الاختبارات nunit-console دقيق عند مقارنته بالتوقيت يدويًا.

أنا شخصياً أود أن أعرّف ذلك على أنه تأثر الأداء؟

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

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

CharliePoole أحصل على نفس السلوك البطيء / السريع باستخدام NUnitLite. وبالنسبة لي فإن الوقت مختلف بشكل ملحوظ.

من الاهتمام. لقد قمت بتجميع مجموعة الاختبار الخاصة بي باستخدام NUnit v2.6.4 واستخدمت عداء وحدة التحكم 2.6.4 لمجموعة الاختبار هذه. تكون مدة الاختبارات سريعة دائمًا بغض النظر عن الفاصل الزمني لمؤقت دقة Windows (تم تأكيده باستخدام ClockRes).

نونيت -2_ fast.txt

لقد استخدمت أيضًا نفس مجموعة اختبار AoC.dll 2.6.4 مع عداء وحدة التحكم 3.7.1 وهي دائمًا سريعة بغض النظر عن الفاصل الزمني لمؤقت دقة Windows.

نونيت -3_ fast.txt

@ Singh400 هذا

عندما تقوم بالتشغيل باستخدام NUnitLite ، يتم تضمين إطار عمل NUnit 3 فقط.

عند التشغيل ضمن NUnit V2 ، لا يتم تضمين مكونات NUnit 3.

عند تشغيل اختبارات NUNit V2 ضمن NUnit 3 ، يتم استخدام وحدة التحكم والمحرك NUnit 3 ، ولكن من الواضح أن إطار العمل ليس كذلك.

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

CharliePoole لقد تمكنت من تضييق نطاق هذه المشكلة بشكل أكبر. عدت وتجميعها جناح اختباري ضد v3.0.0 وأنا لا يمكن إنشاء هذه المشكلة. ظللت أتحرك في الإصدارات حتى ظهرت المشكلة مرة أخرى وهي تفعل ذلك في v3.4.0. الإصدار الأخير الذي لم يكن به هذه المشكلة هو v3.2.1.

هل يمكن لأي شخص آخر إعادة الإنتاج والتأكيد من فضلك؟

هل يمكن لأي شخص آخر إعادة الإنتاج والتأكيد من فضلك؟

@ Singh400 أكد ؛ مع مجموعة الاختبار الخاصة بي ، يستغرق 3.4.0 9.174 ثانية ؛ 3.2.1 تستغرق 1.704 ثانية

لذا ، مهما كانت المشكلة (ما زلت غير قادر على إعادة إنتاجها)

CharliePoole الطريقة الوحيدة التي وجدت أن أكون متأكدًا منها تمامًا عند إعادة الإنتاج هي استخدام clockres الذي ربط @ Singh400 به من قبل وإلقاء نظرة على فاصل المؤقت الحالي. بشكل افتراضي ، تبلغ 15.625 مللي ثانية ، إذا كانت عند ذلك ، فسيكون التشغيل بطيئًا ، وأي شيء آخر سيكون أسرع:

يبدو أن التطبيقات العشوائية تغير الفاصل الزمني للمؤقت ، لذلك كنت أقوم بتشغيله في كل مرة للتحقق من أن الكروم أو Firefox (أو أي تطبيق عشوائي على ما يبدو) لم يغير الفاصل الزمني:

Clockres v2.1 - Clock resolution display utility
Copyright (C) 2016 Mark Russinovich
Sysinternals

Maximum timer interval: 15.625 ms
Minimum timer interval: 0.500 ms
Current timer interval: 15.625 ms

فتح VS:

Clockres v2.1 - Clock resolution display utility
Copyright (C) 2016 Mark Russinovich
Sysinternals

Maximum timer interval: 15.625 ms
Minimum timer interval: 0.500 ms
Current timer interval: 1.000 ms

أول رد فعل لي هو أن البرنامج الذي يغير دقة الساعة ، ويؤثر على البرامج الأخرى ، يكون سلوكًا سيئًا إلى حد ما! رد فعلي الثاني هو أنه ربما يجب على NUnit تغييره. 😄

ومع ذلك ، فإن تغييرها خاص بالنظام الأساسي وهذا شيء نميل إلى تجنبه.

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

أول رد فعل لي هو أن البرنامج الذي يغير دقة الساعة ، ويؤثر على البرامج الأخرى ، يكون سلوكًا سيئًا إلى حد ما! رد فعلي الثاني هو أنه ربما يجب على NUnit تغييره.

هذا دائما خيار!

أبحث حاليًا عن الفرق بين 3.2.1 و 3.4.0 لمعرفة ما إذا كان بإمكاني تحديد شيء تغير لجعل NUnit عرضة لهذا التغيير الذي يؤثر على الأداء. ومع ذلك ، لا أعرف ما الذي أبحث عنه أو الأشياء التي ستتأثر ، لذلك قد يستغرق الأمر بعض الوقت!

تضمين التغريدة

أول رد فعل لي هو أن البرنامج الذي يغير دقة الساعة ، ويؤثر على البرامج الأخرى ، يكون سلوكًا سيئًا إلى حد ما!

أنا موافق. لكن شيئًا ما تغير بين 3.2.1 و 3.4.0 مما جعل NUnit حساسًا لمؤقت دقة Windows. لقد حاولت ومراجعة التغييرات بين النسختين ، لكن بالنظر إلى أنني لست على دراية بهندسة NUnit فقد استسلمت.

لقد قمت بتجميع ملف ZIP مع كل ما يلزم لإظهار المدد المختلفة

https://github.com/Singh400/aoc/blob/master/TestSuite.zip

يبدو الإخراج كالتالي : -

===== Current Clock Res should be 15ms. If not something is changing it.

Current timer interval: 15.627 ms

===== Running TestSuite compiled with nUnit 3.4.0. This is the SLOW run

    Duration: 7.744 seconds

===== Current Clock Res should be 15ms. If not something is changing it.

Current timer interval: 15.627 ms

===== Now changing the Clock Res

===== Current Clock Res should be 0.5ms. If not something is changing it.

Current timer interval: 0.501 ms

===== Running TestSuite compiled with nUnit 3.4.0. This is the FAST run

    Duration: 1.147 seconds

===== Now resetting the Clock Res

===== Current Clock Res should be 15ms. If not something is changing it.

Current timer interval: 15.627 ms

===== Running TestSuite compiled with nUnit 3.2.1. WITHOUT changing the Clock Res.

    Duration: 0.596 seconds

@ Singh400 https://github.com/Singh400/nunit/blob/master/TestSuite.zip هو 404

mintsoft فقط

اللعب مع trace=Verbose والنظر في ملفات السجل الناتجة يكشف اختلافًا واحدًا فقط. يحتوي ملف السجل للتشغيل مع 3.4.0 على هذا السطر في: -

00:38:55.327 Info [ 9] WorkItemQueue: NonParallelQueue pausing

في حين أن ملف السجل لـ 3.2.1 لا يفعل ذلك.

مقتطف لملف السجل 3.4.0

00:38:55.303 Info  [ 9] TestWorker: Worker#STA_NP executing Problem12Tests
00:38:55.304 Debug [ 9] WorkItemDispatcher: Directly executing PartOne
00:38:55.311 Info  [ 9] TestWorker: Worker#STA_NP executing Problem13Tests
00:38:55.312 Debug [ 9] WorkItemDispatcher: Directly executing TestThing
00:38:55.323 Info  [ 9] WorkShift: NonParallel shift ending
00:38:55.327 Info  [ 9] WorkItemQueue: NonParallelQueue pausing
00:38:55.327 Info  [ 9] WorkItemQueue: NonParallelQueue stopping - 18 WorkItems processed, max size 17
00:38:55.327 Info  [ 9] TestWorker: Worker#STA_NP stopping - 18 WorkItems processed.

مقتطف من ملف السجل 3.2.1

00:38:55.993 Info  [ 9] TestWorker: Worker#STA_NP executing Problem12Tests
00:38:55.993 Debug [ 9] WorkItemDispatcher: Directly executing PartOne
00:38:55.993 Info  [ 9] TestWorker: Worker#STA_NP executing Problem13Tests
00:38:55.993 Debug [ 9] WorkItemDispatcher: Directly executing TestThing
00:38:56.118 Info  [ 9] WorkShift: NonParallel shift ending
00:38:56.118 Info  [ 9] WorkItemQueue: NonParallelQueue stopping - 18 WorkItems processed, max size 17
00:38:56.118 Info  [ 9] TestWorker: Worker#STA_NP stopping - 18 WorkItems processed.

ليس لدي أي فكرة عما إذا كان ذلك مرتبطًا (مجرد تخمين) ولكن البحث عن ارتباطات بين 3.2.1 -> 3.4.0 للكلمة الرئيسية "إيقاف مؤقت" يكشف عن هذا الالتزام: https://github.com/nunit/nunit/commit/ bb86737a16ad03ee22777848fa6e3064b9664812

لا أرى ارتباطًا كبيرًا بمشكلة التوقيت. إيقاف قائمة الانتظار مؤقتًا لا يوقف الوقت.

سيكون الأمر قليلًا من العمل ، ولكن يمكنك الاستمرار في محاولة إنشاءات بين 3.2.1 و 3.4 ، وإجراء بحث ثنائي. جميع العناصر التي تم إنشاؤها لإتقانها موجودة في موجز MyGet الخاص بنا.

@ Singh400 قد يكون ذلك لأنه ، ما لم أكن مخطئًا ، تحدد دقة المؤقت دقة الوقت القصير الذي يمكنك فيه النوم. لذا ، فإن Thread.Sleep (1) سينام 15 مللي ثانية إذا كانت دقة المؤقت 15 مللي ثانية.

تدق ساعة النظام بمعدل معين يسمى دقة الساعة. قد لا تكون المهلة الفعلية هي المهلة المحددة تمامًا ، لأنه سيتم تعديل المهلة المحددة لتتوافق مع علامات الساعة. لمزيد من المعلومات حول دقة الساعة ووقت الانتظار ، انظر موضوع وظيفة السكون. تستدعي هذه الطريقة وظيفة السكون من واجهات برمجة تطبيقات نظام Windows.
https://msdn.microsoft.com/en-us/library/d00bd51t (v = مقابل 110) .aspx

. لذا ، فإن Thread.Sleep (1) سينام 15 مللي ثانية إذا كانت دقة المؤقت 15 مللي ثانية.

هذه مكالمة جيدة ويبدو مرجحًا بشكل معقول ، ولكن في https://github.com/nunit/nunit/commit/bb86737a16ad03ee22777848fa6e3064b9664812 ، يكون النوم (1) (أو ما شابه) ضمن #if لـ net. 2 / 3.5 / مضغوط ونحن هنا .net 4. أعتقد أنه من المعقول أيضًا أن Thread.Y قد ينتظر فترات 15 مللي ثانية ، لكن هذا يبدو طويلًا جدًا بالنسبة للقسم الزمني للخيط.

تحرير: لاحظت للتو Thread.SpinWait

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

هذا غامض إلى حد معقول ، لكنني أتساءل عما إذا كان ذلك متعلقًا بالمؤقت

تحية للجميع،

أعتقد أنني وجدت الالتزام الذي أدخل هذا الانحدار ؛ 9086990

هل يمكن لأي شخص آخر أن يؤكد من فضلك؟

هتافات،
إندي

عمل مخبر جيد! نحتاج إلى معرفة سبب احتياجنا لذلك. إذا كان __فقط__ بالنسبة إلى CF ، فيمكننا تغييره مرة أخرى. oznetmaster هل تتذكر هذا؟

لقد غيرنا إلى Sleep (1) من Sleep (0) لأن Microsoft أصدرت مستندًا ينص بشكل أساسي على أنه لا ينبغي استخدام Sleep (0) أبدًا!

لا علاقة له ببناء CF.

أعتقد أنني أشرت إلى المستند في الإصدار الأصلي. لم أبحث عنها ، لكن يجب أن تكون موجودة.

أعتقد أنه يمكن استخدام Thread.Yield () بدلاً من ذلك ، ولكن كانت هناك مشكلات في ذلك أيضًا (إلى جانب حقيقة أنه غير موجود في CF).

أعتقد أنه يمكن استخدام Thread.Yield () بدلاً من ذلك ، ولكن كانت هناك مشكلات في ذلك أيضًا (إلى جانب حقيقة أنه غير موجود في CF).

لن يسمح IIRC Thread.Yield بتقسيم سلسلة رسائل من نواة أخرى إلى شرائح زمنية ، فقط الخيوط المجدولة للتنفيذ على النواة التي تم إنتاجها. أي أنها لا تفرض تبديل السياق

هل هناك سبب لتشغيل خيط مضخة الحدث بأولوية قصوى؟ يبدو لي تعليق الالتزام بأنه يعمل على حل المأزق غريباً. دائمًا ما يكون صعبًا عند العبث بأولويات الموضوع.

@ appel1 من أين يأتي هذا؟ يجب ألا يكون لولب مضخة الحدث أولوية قصوى على الإطلاق. يقوم بإجراء مكالمات حظر لمعالجات الأحداث غير المعروفة.

CharliePoole https://github.com/nunit/nunit/blob/master/src/NUnitFramework/framework/Internal/Execution/EventPump.cs#L143

رائع! كان هذا موجودًا منذ NUnit 2. في ذلك الوقت ، كان الأمر أكثر منطقية. كان لدينا سيطرة على معالجي الأحداث وعرفنا ما فعلوه. واستخدام أولوية أعلى جعل من الممكن لـ Sleep (0) العمل.

من المحتمل أن أفتقد شيئًا ما ولكن لا يمكنني ملاحظة أي مشكلات باستخدام وحدة التحكم nunit أو nunit-gui أو R # إذا قمت بإزالة تغيير أولوية مؤشر الترابط والنوم في dequeue حتى عند إجراء الاختبارات قيد التشغيل.

ما المشكلة التي يحاول هذا الرمز حلها؟ لا يمكنك الوصول إلى أي أجهزة ذات نواة واحدة لا تحتوي على ht للاختبار عليها ، فربما يكون هذا هو الحال.

        public void Enqueue(Event e)
        {
            // Add to the collection
            _queue.Enqueue(e);

            // Wake up threads that may have been sleeping
            _mreAdd.Set();
        }

        public Event Dequeue(bool blockWhenEmpty)
        {
            do
            {
                // Dequeue our work item
                Event e;
                if (_queue.TryDequeue (out e))
                {
                    return e;
                }

                if (!blockWhenEmpty || Interlocked.CompareExchange(ref _stopped, 0, 0) != 0)
                    return null;

                _mreAdd.Wait(-1);

                if (Interlocked.CompareExchange(ref _stopped, 0, 0) != 0)
                    return null;

            } while (true);
        }

أميل إلى التخلي عن تحديد الأولويات والنوم ومعرفة ما سيحدث خلال الشهر المقبل. يمكننا التعديل قبل الإصدار إذا كان علينا ذلك.

هل اقتربنا من اختيار الحل (# 2233 أو # 2236)؟ لقد مر 18 يومًا منذ طرح المشكلة ، و 14 يومًا منذ تحديد الانحدار في الالتزام 9086990.

يقرأ على هذا النحو أن غالبية الأشخاص يفضلون # 2236 وفي هذه الحالة يمكنني إغلاق # 2233 ويمكننا فقط التركيز على الحصول على # 2236 في الإصدار التالي.

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

نظرًا لأن لدينا اثنين من العلاقات العامة ، سألخص هنا ...

2233 ببساطة يغير فترة السكون. كان لديه مراجعة واحدة من @ jnm2 الذي طلب التغييرات.

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

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

• rprouse وافق على هذا للدمج.
• رفضت المراجعة ولكن قدمت بعض التعليقات. أنا قلق من أن التغييرات "الإضافية" في هذا العلاقات العامة قد تكسر ما تم إصلاحه قبل عام ... نقص عام في الاستجابة في واجهة المستخدم الرسومية. بصراحة ، لم أكن لأعرف كيف أفعل ما فعله oznetmaster ، سأعود وأقوم بواحد.

سأقوم بإضافة تعليقات إلى كل العلاقات العامة. أميل إلى استخدام # 2233 على الفور والضغط على # 2236 لمزيد من المناقشة. يقومoznetmaster بتغيير القارات في الوقت الحالي وسيصبح متاحًا في النهاية مرة أخرى. سيجعل الرقم 2233 التغيير متاحًا في موجز MyGet الخاص بنا لأي شخص يريد إصلاحًا فوريًا.

لقد لاحظت أن هذا لا يزال يحمل علامة على أنه يحتاج إلى تأكيد ، على الرغم من تأكيده منذ فترة. سوف إصلاح.

نظرًا لأن هذا تم إصلاحه بواسطة # 2233 ، فهل يجب علينا إغلاق هذه المشكلة ، أم هل يجب أن نبقيها مفتوحة أثناء مناقشة # 2236؟

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

أكد jskeet أن # 2233 قد حل مشكلته كما ورد في nunit / dotnet-test-nunit # 109. # 2236 وهذه القضية صامتة فهل ننهيها؟

أعتقد أن دمج # 2233 كان يهدف إلى إغلاق هذا.

أعتقد أنه بناءً على https://github.com/nunit/nunit/issues/2217#issuecomment -310516474 ، كنت تريد إبقائه مفتوحًا حتى يتم اتخاذ قرار باستخدام https://github.com/nunit/nunit/pull/2236

آه .. الكثير من القضايا ، الكثير من التعليقات. :ابتسامة:

ما زلت أقول إغلاقها. المراجع من القضية الأخرى ستظل موجودة.

هذا جيد بالنسبة لي

تم الإصلاح بواسطة https://github.com/nunit/nunit/pull/2233

من خلال قراءة كتابة @ indy-singh الرائعة على https://medium.com/@indy_singh/fixing -nunit-slow-test -ecution-a67c284355c4 ، أدركت أن JetBrains اختارت عدم استخدام Sleep (0) لأنه ليس مضمونًا العائد ، كما ناقشنا في عدة مواضيع. بدلاً من ذلك ، يستخدمون timeBeginPeriod / timeEndPeriod لجعل Windows يتحول إلى دقة أكثر دقة. (انظر https://youtrack.jetbrains.com/issue/PROF-715#focus=streamItem-27-2769768-0-0).