أوقات الترجمة بطيئة جدًا في Visual Studio 2005

https://stackoverflow.com/questions/55517

09-06-2019
|

سؤال

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

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

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

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

تحديثلقد أهملت أن أذكر أن هذا هو حل C#.شكرًا لجميع اقتراحات لغة C++، ولكن مرت سنوات قليلة منذ أن شعرت بالقلق بشأن الرؤوس.

يحرر:

اقتراحات جميلة ساعدت حتى الآن (لا أقول إنه لا توجد اقتراحات لطيفة أخرى أدناه، فقط ما ساعد)

كمبيوتر محمول جديد بسرعة 3 جيجاهرتز - قوة الاستخدام المفقود تصنع العجائب عند التذمر من الإدارة
تعطيل مكافحة الفيروسات أثناء التجميع
"قطع الاتصال" عن VSS (في الواقع الشبكة) أثناء الترجمة - قد أطلب منا إزالة تكامل VS-VSS تمامًا والالتزام باستخدام واجهة مستخدم VSS

لا يزال لا يتم نسخه من خلال التجميع، ولكن كل جزء منه يساعد.

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

الحل البديل

نحن نختبر ممارسة بناء مناطق جديدة من التطبيق في حلول جديدة، واستيرادها في أحدث ملفات dll كما هو مطلوب، ودمجها في الحل الأكبر عندما نكون سعداء بها.

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

المحلول

قام فريق Chromium.org بإدراج عدة خيارات لـ تسريع البناء (في هذه المرحلة في منتصف الصفحة تقريبًا):

بالترتيب التنازلي للسرعة:

قم بتثبيت الإصلاح العاجل لـ Microsoft 935225.

قم بتثبيت الإصلاح العاجل لـ Microsoft 947315.

استخدم معالجًا حقيقيًا متعدد النواة (أي.إنتل كور ديو 2؛وليس بنتيوم 4 HT).

استخدم 3 بنيات متوازية.في Visual Studio 2005، ستجد الخيار في أدوات > خيارات...> المشاريع والحلول > البناء والتشغيل > الحد الأقصى لعدد عمليات إنشاء المشروع الموازية.

قم بتعطيل برنامج مكافحة الفيروسات الخاص بك لملفات .ilk و.pdb و.cc و.h وتحقق فقط من وجود فيروسات على يُعدِّل.قم بتعطيل فحص الدليل الذي توجد به مصادرك.لا تفعل أي شيء غبي.

قم بتخزين وإنشاء كود Chromium على محرك أقراص ثابت ثانٍ.لن يؤدي ذلك إلى تسريع عملية الإنشاء حقًا، ولكن على الأقل سيظل جهاز الكمبيوتر الخاص بك مستجيبًا عند إجراء مزامنة gclient أو الإنشاء.

قم بإلغاء تجزئة القرص الصلب الخاص بك بانتظام.

تعطيل الذاكرة الافتراضية.

نصائح أخرى

لدينا ما يقرب من 100 مشروع في حل واحد ووقت إنشاء التطوير هو ثوانٍ فقط :)

من أجل بناء التطوير المحلي، قمنا بإنشاء Visual Studio Addin الذي يتغير Project references ل DLL references وتفريغ المشاريع غير المرغوب فيها (وخيار إعادتها بالطبع).

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

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

تحديث مايو 2015

كانت الصفقة التي أبرمتها (في التعليقات أدناه) هي أنني سأطلق البرنامج الإضافي إلى المصدر المفتوح لو فإنه يحصل على ما يكفي من الاهتمام.وبعد مرور 4 سنوات، حصل على 44 صوتًا فقط (ولدى Visual Studio الآن نسختان لاحقتان)، لذا فهو حاليًا مشروع ذو أولوية منخفضة.

واجهت مشكلة مماثلة بشأن حل 21 مشروعًا و1/2 مليون LOC.كان الاختلاف الأكبر هو الحصول على محركات أقراص ثابتة أسرع.من شاشة الأداء يظهر "المتوسط".سوف تقفز قائمة انتظار القرص بشكل ملحوظ على الكمبيوتر المحمول مما يشير إلى أن محرك الأقراص الثابتة هو عنق الزجاجة.

إليك بعض البيانات الخاصة بإجمالي أوقات إعادة البناء...

1) كمبيوتر محمول، Core 2 Duo بسرعة 2 جيجا هرتز، محرك بسرعة 5400 دورة في الدقيقة (لست متأكدًا من ذاكرة التخزين المؤقت.كان معيار ديل انسبايرون).

وقت إعادة البناء = 112 ثانية.

2) سطح المكتب (إصدار قياسي)، Core 2 Duo بسرعة 2.3 جيجا هرتز، محرك أقراص فردي بسرعة 7200 دورة في الدقيقة وذاكرة تخزين مؤقت سعة 8 ميجابايت.

وقت إعادة البناء = 72 ثانية.

3) سطح المكتب Core 2 Duo 3 جيجا هرتز، 10000 دورة في الدقيقة WD Raptor فردي

وقت إعادة البناء = 39 ثانية.

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

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

بالنسبة لإصدارات C# .NET، يمكنك استخدامها صافي شيطان.إنه منتج يتولى عملية إنشاء Visual Studio لجعلها أسرع.

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

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

استخدم التجميع الموزع.زوريكس إنكريديبيلد يمكن أن يقلل وقت التجميع إلى بضع دقائق.

لقد استخدمته في حل C\C++ ضخم والذي يستغرق تجميعه عادةً من 5 إلى 6 ساعات.ساعد IncrediBuild في تقليل هذا الوقت إلى 15 دقيقة.

إرشادات لتقليل وقت ترجمة Visual Studio الخاص بك إلى بضع ثوانٍ

للأسف، Visual Studio ليس ذكيًا بما يكفي للتمييز بين تغييرات واجهة التجميع والتغييرات غير المهمة في نص التعليمات البرمجية.هذه الحقيقة، عند دمجها مع حلول كبيرة متشابكة، يمكنها أحيانًا إنشاء عاصفة كاملة من "الإنشاءات الكاملة" غير المرغوب فيها في كل مرة تقوم فيها بتغيير سطر واحد من التعليمات البرمجية تقريبًا.

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

يمكنك التبديل من تكوين بناء إلى آخر عبر القائمة المنسدلة لتكوين البناء في الجزء العلوي من شاشة IDE (التي تظهر عادةً إما "تصحيح" أو "إصدار").على نحو فعال، سيؤدي تكوين بناء ManualCompile الجديد هذا إلى جعل خيارات قائمة Build عديمة الفائدة من أجل:"بناء الحل" أو "إعادة بناء الحل".وبالتالي، عندما تكون في وضع ManualCompile، يجب عليك إنشاء كل مشروع تقوم بتعديله يدويًا، وهو ما يمكن القيام به عن طريق النقر بزر الماوس الأيمن على كل مشروع متأثر في Solution Explorer، ثم تحديد "إنشاء" أو "إعادة البناء".يجب أن ترى أن إجمالي أوقات الترجمة الخاصة بك سيكون الآن مجرد ثوانٍ.

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

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

إذا كان هذا هو C أو C++، وكنت لا تستخدم الرؤوس المترجمة مسبقًا، فيجب أن تكون كذلك.

كان لدينا أكثر من 80 مشروعًا في حلنا الرئيسي والذي استغرق إنشاؤه حوالي 4 إلى 6 دقائق اعتمادًا على نوع الآلة التي كان يعمل عليها المطور.لقد اعتبرنا أن هذا طويل جدًا:ففي مقابل كل اختبار، فإنه يؤدي بالفعل إلى تآكل معدلات FTE الخاصة بك.

فكيف تحصل على أوقات بناء أسرع؟كما يبدو أنك تعلم بالفعل، فإن عدد المشاريع هو الذي يضر حقًا بوقت البناء.بالطبع لم نرغب في التخلص من جميع مشاريعنا ورمي جميع ملفات المصدر في ملف واحد.لكن كان لدينا بعض المشاريع التي يمكننا دمجها مع ذلك:نظرًا لأن كل "مشروع مستودع" في الحل لديه مشروع اختبار الوحدة الخاص به، فقد قمنا ببساطة بدمج جميع مشاريع اختبار الوحدة في مشروع واحد عالمي.أدى ذلك إلى خفض عدد المشاريع بحوالي 12 مشروعًا وتوفير 40% من الوقت لبناء الحل بأكمله بطريقة أو بأخرى.

نحن نفكر في حل آخر بالرغم من ذلك.

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

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

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

تأكد من أن المراجع الخاصة بك هي مراجع المشروع، وليست مباشرة إلى مكتبات الارتباط الحيوي (DLL) الموجودة في أدلة إخراج المكتبة.

أيضًا، قم بضبطها على عدم النسخ محليًا إلا عند الضرورة القصوى (مشروع EXE الرئيسي).

لقد نشرت هذا الرد في الأصل هنا:https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473يمكنك العثور على العديد من التلميحات المفيدة الأخرى على تلك الصفحة.

إذا كنت تستخدم Visual Studio 2008، فيمكنك التحويل البرمجي باستخدام علامة /MP لإنشاء مشروع واحد بالتوازي.لقد قرأت أن هذه أيضًا ميزة غير موثقة في Visual Studio 2005، لكنني لم أجرّبها بنفسي مطلقًا.

يمكنك إنشاء مشاريع متعددة بالتوازي باستخدام علامة /M، ولكن عادةً ما يتم تعيين هذا بالفعل على عدد النوى المتوفرة على الجهاز، على الرغم من أن هذا ينطبق فقط على VC++ على ما أعتقد.

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

بعض الموارد الإضافية:

بعض أدوات التحليل:

أدوات-> خيارات-> إعدادات المشروع VC ++-> إنشاء توقيت = نعم سيخبرك وقت البناء لكل VCProj.

يضيف /Bt قم بالتبديل إلى سطر أوامر المترجم لمعرفة مقدار ما يستغرقه كل ملف CPP

يستخدم /showIncludes لالتقاط التضمينات المتداخلة (ملفات الرأس التي تتضمن ملفات رأس أخرى)، ومعرفة الملفات التي يمكن أن توفر الكثير من عمليات الإدخال/الإخراج باستخدام الإعلانات الأمامية.

سيساعدك هذا على تحسين أداء المترجم من خلال التخلص من التبعيات وخنازير الأداء.

قبل إنفاق المال للاستثمار في محركات أقراص ثابتة أسرع، حاول بناء مشروعك بالكامل على قرص ذاكرة الوصول العشوائي (على افتراض أن لديك ذاكرة وصول عشوائي كافية).يمكنك العثور على العديد من برامج تشغيل قرص RAM المجانية على الشبكة.لن تجد أي محرك أقراص فعلي، بما في ذلك محركات أقراص SSD، أسرع من قرص ذاكرة الوصول العشوائي (RAM).

في حالتي، تم تقليل المشروع الذي استغرق 5 دقائق للبناء على معالج i7 سداسي النواة على محرك أقراص SATA بسرعة 7200 دورة في الدقيقة مع Incredibuild بحوالي 15 ثانية فقط باستخدام قرص RAM.وبالنظر إلى الحاجة إلى إعادة النسخ إلى وحدة التخزين الدائمة واحتمال فقدان العمل، فإن 15 ثانية لا تمثل حافزًا كافيًا لاستخدام قرص ذاكرة الوصول العشوائي (RAM) وربما لا تمثل حافزًا كبيرًا لإنفاق عدة مئات من الدولارات على محرك أقراص SSD أو محرك أقراص ذو سرعة دوران عالية.

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

اعتمادًا على الكود الفعلي الذي تقوم بتجميعه، قد يختلف عدد الأميال المقطوعة - لذا لا تتردد في الاختبار.

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

إليك بعض النصائح المفيدة من باتريك سماتشيا، مؤلف كتاب NDepend، حول ما يعتقد أنه ينبغي وما لا ينبغي أن يكون تجميعات منفصلة:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

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

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

إذا كنت قلقًا بشأن اختلاط الإصدارات المختلفة من ملفات DLL، فاستخدم المكتبات الثابتة.

قم بإيقاف تشغيل تكامل VSS.قد لا يكون لديك خيار في استخدامه، ولكن تتم إعادة تسمية ملفات DLL "عن طريق الخطأ" طوال الوقت...

وبالتأكيد تحقق من إعدادات الرأس المترجمة مسبقًا.دليل بروس داوسون قديم بعض الشيء، لكنه لا يزال جداً جيد - التحقق من ذلك: http://www.cygnus-software.com/papers/precompiledheaders.html

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

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

يقوم الملف الدفعي أيضًا بنسخ النتيجة المكتملة إلى مجلدات الاختبار (أو عدة).اعتمادًا على الإعدادات، يكتمل هذا في عدة ثوانٍ إلى دقيقة (بدلاً من نصف ساعة على سبيل المثال).

لقد استخدمت IDE مختلفًا (Zeus) لأنني أحب التحكم في أشياء مثل ملفات .rc، وفي الواقع أفضل التجميع من سطر الأوامر، على الرغم من أنني أستخدم برامج MS المتوافقة.

يسعدني نشر مثال على هذا الملف الدفعي إذا كان أي شخص مهتمًا.

قم بتعطيل فهرسة نظام الملفات في أدلة المصدر الخاصة بك (على وجه التحديد أدلة obj إذا كنت تريد أن يكون مصدرك قابلاً للبحث)

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

<compilation defaultLanguage="c#" debug="true" batch="true" >

يمكنك العثور على نظرة عامة هنا: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

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

إنه:

المشروع أ يشير إلى المشروع ب

يشير المشروع ب إلى المشروع ج

يشير المشروع C إلى المشروع A

أحد البدائل الأرخص لـ Xoreax IB هو استخدام ما أسميه بنيات ملف uber.إنه في الأساس ملف .cpp يحتوي على

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

ثم تقوم بتجميع وحدات uber بدلاً من الوحدات الفردية.لقد رأينا أوقات التجميع من 10-15 دقيقة إلى 1-2 دقيقة.قد يتعين عليك تجربة عدد #التضمينات المنطقية لكل ملف uber.يعتمد على المشاريع.إلخ.ربما تقوم بتضمين 10 ملفات، وربما 20.

أنت تدفع تكلفة لذا احذر:

لا يمكنك النقر بزر الماوس الأيمن فوق ملف وقول "ترجمة..." حيث يتعين عليك استبعاد ملفات cpp الفردية من الإصدار وتضمين ملفات uber cpp فقط
عليك أن تكون حذراً من تعارضات المتغيرات العالمية الثابتة.
عند إضافة وحدات جديدة، يجب عليك إبقاء ملفات uber محدثة

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

إذا كان مشروعًا بلغة C++، فيجب عليك استخدام الرؤوس المترجمة مسبقًا.وهذا يحدث فرقًا كبيرًا في أوقات الترجمة.لست متأكدًا مما يفعله cl.exe بالفعل (مع عدم استخدام الرؤوس المترجمة مسبقًا)، يبدو أنه يبحث عنه الكثير من رؤوس STL في جميع الأماكن الخاطئة قبل الانتقال أخيرًا إلى الموقع الصحيح.يؤدي هذا إلى إضافة ثوانٍ كاملة إلى كل ملف .cpp يتم تجميعه.لست متأكدًا مما إذا كان هذا خطأ cl.exe، أو مشكلة من نوع STL في VS2008.

بالنظر إلى الجهاز الذي تبني عليه، هل تم تكوينه على النحو الأمثل؟

لقد حصلنا للتو على وقت بناء لأكبر منتج على مستوى المؤسسات بلغة C++ 19 ساعة ل 16 دقيقة من خلال التأكد من تثبيت برنامج تشغيل مرشح SATA الصحيح.

دقيق.

يوجد مفتاح /MP غير موثق في Visual Studio 2005، انظر http://lahsiv.net/blog/?p=40, ، والتي من شأنها تمكين التجميع المتوازي على أساس الملف بدلاً من أساس المشروع.قد يؤدي هذا إلى تسريع عملية ترجمة المشروع الأخير، أو إذا قمت بتجميع مشروع واحد.

عند اختيار وحدة المعالجة المركزية:يبدو أن حجم ذاكرة التخزين المؤقت L1 له تأثير كبير على وقت الترجمة.أيضًا، من الأفضل عادةً أن يكون لديك نواتان سريعتان بدلاً من 4 نوات بطيئة.لا يستخدم Visual Studio النوى الإضافية بشكل فعال.(أبني هذا على تجربتي مع مترجم C++، ولكن من المحتمل أن يكون هذا صحيحًا أيضًا بالنسبة إلى مترجم C#.)

أنا أيضًا مقتنع الآن بوجود مشكلة في VS2008.أقوم بتشغيله على كمبيوتر محمول Intel ثنائي النواة مزود بـ 3G Ram، مع إيقاف تشغيل برنامج مكافحة الفيروسات.غالبًا ما يكون تجميع الحل أمرًا سهلاً للغاية، ولكن إذا كنت قد قمت بتصحيح أخطاء عملية إعادة الترجمة اللاحقة، فغالبًا ما ستتباطأ عملية الزحف.يتضح من ضوء القرص الرئيسي المستمر أن هناك عنق الزجاجة في الإدخال / الإخراج للقرص (يمكنك سماعه أيضًا).إذا قمت بإلغاء الإنشاء وإيقاف التشغيل VS، فسيتوقف نشاط القرص.أعد تشغيل VS، وأعد تحميل الحل ثم أعد البناء، وهو أسرع بكثير.الوحدة في المرة القادمة

أفكاري هي أن هذه مشكلة ترحيل صفحات الذاكرة - نفدت ذاكرة VS للتو ويبدأ O/S في تبديل الصفحة لمحاولة توفير مساحة ولكن VS يتطلب أكثر مما يمكن أن يحققه مبادلة الصفحات، لذلك يتباطأ إلى حد الزحف.لا أستطيع التفكير في أي تفسير آخر.

VS بالتأكيد ليست أداة RAD، أليس كذلك؟

هل تستخدم شركتك Entrust لحل البنية التحتية للمفاتيح العامة/التشفير الخاص بها بأي حال من الأحوال؟اتضح أننا كنا نواجه أداءً سيئًا في بناء موقع ويب كبير إلى حد ما تم إنشاؤه باستخدام لغة C#، واستغرق الأمر أكثر من 7 دقائق في Rebuild-All.

جهازي هو i7-3770 مع ذاكرة وصول عشوائي سعتها 16 جيجابايت ومحرك أقراص SSD سعة 512 جيجابايت، لذا لا ينبغي أن يكون الأداء بهذا السوء.لقد لاحظت أن أوقات البناء الخاصة بي كانت أسرع بجنون على جهاز ثانوي أقدم يقوم ببناء نفس قاعدة التعليمات البرمجية.لذلك قمت بتشغيل ProcMon على كلا الجهازين، وقمت بتجميع لمحة عن التصميمات، ومقارنة النتائج.

وها هو الجهاز ذو الأداء البطيء لديه اختلاف واحد - إشارة إلى Entrust.dll في نظام تتبع المكدس.باستخدام هذه المعلومات المكتسبة حديثًا، واصلت البحث في StackOverflow ووجدت ما يلي: MSBUILD (VS2010) بطيء جدًا في بعض الأجهزة.وفقًا للإجابة المقبولة، تكمن المشكلة في حقيقة أن معالج Entrust كان يعالج عمليات التحقق من شهادة .NET بدلاً من معالج Microsoft الأصلي.يُقترح أيضًا أن يقوم Entrust v10 بحل هذه المشكلة السائدة في Entrust 9.

لقد قمت حاليًا بإلغاء تثبيته وانخفضت أوقات البناء الخاصة بي 24 ثانية.YYMV مع عدد المشاريع التي تقوم بإنشائها حاليًا وقد لا تعالج بشكل مباشر مشكلة التوسع التي كنت تستفسر عنها.سأقوم بنشر تعديل على هذا الرد إذا كان بإمكاني تقديم إصلاح بدون اللجوء إلى إلغاء تثبيت البرنامج.

من المؤكد أن هناك مشكلة في VS2008.لأن الشيء الوحيد الذي قمت به هو تثبيت VS2008 لترقية مشروعي الذي تم إنشاؤه باستخدام VS2005.لدي مشروعان فقط في الحل الخاص بي.انها ليست كبيرة.تجميع مع VS2005:30 ثانية تجميع مع VS2008:5 دقائق

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

كمبيوتر محمول جديد بسرعة 3 جيجاهرتز - قوة الاستخدام المفقود تصنع العجائب عند التذمر من الإدارة
تعطيل مكافحة الفيروسات أثناء التجميع
"قطع الاتصال" عن VSS (في الواقع الشبكة) أثناء الترجمة - قد أطلب منا إزالة تكامل VS-VSS تمامًا والالتزام باستخدام واجهة مستخدم VSS

لا يزال لا يتم نسخه من خلال التجميع، ولكن كل جزء منه يساعد.

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow