เราได้รับเวลาในการคอมไพล์ที่ช้ามากซึ่งอาจใช้เวลามากกว่า 20 นาทีบนเครื่อง 2GHz 2GHz, 2G Ram

ส่วนใหญ่เกิดจากขนาดของโซลูชันของเราที่เติบโตขึ้นเป็น 70+ โปรเจ็กต์เช่นเดียวกับ VSS ซึ่งเป็นคอขวดในตัวเมื่อคุณมีไฟล์จำนวนมาก (การแลกเปลี่ยน VSS ไม่ใช่ตัวเลือกที่น่าเสียดายดังนั้นฉันไม่ต้องการให้สิ่งนี้ลงไปสู่การทุบตี VSS)

เรากำลังดูการรวมโครงการ นอกจากนี้เรากำลังมองหาวิธีแก้ปัญหาที่หลากหลายเพื่อให้แยกข้อกังวลได้มากขึ้นและรวบรวมเวลาที่รวดเร็วขึ้นสำหรับแต่ละองค์ประกอบของแอปพลิเคชัน สิ่งนี้ที่ฉันเห็นจะกลายเป็นนรกของ DLL ในขณะที่เราพยายามซิงค์สิ่งต่างๆ

ฉันสนใจที่จะทราบว่าทีมอื่น ๆ จัดการกับปัญหาการปรับขนาดนี้อย่างไรคุณจะทำอย่างไรเมื่อฐานรหัสของคุณถึงจำนวนวิกฤตที่คุณเสียเวลาครึ่งวันในการดูแถบสถานะส่งข้อความที่รวบรวม

UPDATE ฉันละเลยที่จะพูดถึงนี่คือโซลูชัน C # ขอบคุณสำหรับคำแนะนำ C ++ ทั้งหมด แต่เป็นเวลาสองสามปีแล้วที่ฉันต้องกังวลเกี่ยวกับส่วนหัว

แก้ไข:

คำแนะนำที่ดีที่ช่วยได้จนถึงตอนนี้ (ไม่ได้บอกว่าไม่มีคำแนะนำที่ดีอื่น ๆ ด้านล่าง แต่สิ่งที่ช่วยได้)

• แล็ปท็อป 3GHz รุ่นใหม่ - พลังแห่งการใช้ประโยชน์ที่หายไปจะทำงานได้อย่างมหัศจรรย์เมื่อต้องการจัดการ
• ปิดใช้งานโปรแกรมป้องกันไวรัสระหว่างการคอมไพล์
• 'ตัดการเชื่อมต่อ' จาก VSS (จริงๆแล้วคือเครือข่าย) ในระหว่างการคอมไพล์ - ฉันอาจให้เราลบการรวม VS-VSS ทั้งหมดและยึดติดกับการใช้ VSS UI

ยังไม่ฉีกขาดผ่านการคอมไพล์ แต่ทุกบิตช่วยได้

Orion กล่าวถึงในความคิดเห็นว่ายาชื่อสามัญอาจมีส่วนร่วมด้วย จากการทดสอบของฉันดูเหมือนว่าจะได้รับผลกระทบด้านประสิทธิภาพเพียงเล็กน้อย แต่ไม่สูงพอที่จะแน่ใจได้ - เวลาในการคอมไพล์อาจไม่สอดคล้องกันเนื่องจากกิจกรรมของดิสก์ เนื่องจากข้อ จำกัด ด้านเวลาการทดสอบของฉันจึงไม่ได้รวม Generics หรือโค้ดมากเท่าที่จะปรากฏในระบบที่ใช้งานจริงดังนั้นจึงอาจสะสมได้ ฉันจะไม่หลีกเลี่ยงการใช้ยาชื่อสามัญในที่ที่ควรใช้เพียงเพื่อรวบรวมประสิทธิภาพของเวลา

การหลีกเลี่ยงปัญหา

เรากำลังทดสอบการปฏิบัติในการสร้างพื้นที่ใหม่ของแอปพลิเคชันในโซลูชันใหม่โดยนำเข้าใน dlls ล่าสุดตามความต้องการซึ่งรวมเข้ากับโซลูชันขนาดใหญ่เมื่อเราพอใจกับสิ่งเหล่านี้

เราอาจทำเช่นเดียวกันกับโค้ดที่มีอยู่โดยการสร้างโซลูชันชั่วคราวที่เพียงแค่ห่อหุ้มส่วนที่เราต้องดำเนินการแล้วทิ้งไปหลังจากที่รวมโค้ดใหม่ เราจำเป็นต้องชั่งน้ำหนักเวลาที่จะรวมรหัสนี้ใหม่กับเวลาที่เราได้รับจากการไม่มี Rip Van Winkle เหมือนกับประสบการณ์ที่มีการคอมไพล์ใหม่อย่างรวดเร็วในระหว่างการพัฒนา

ทีม Chromium.org แสดงรายการตัวเลือกต่างๆสำหรับการเร่งการสร้าง (ณ จุดนี้ประมาณครึ่งทางของหน้า):

ตามลำดับการลดความเร็ว:

• ติดตั้ง Microsoft โปรแกรมแก้ไขด่วน935225
• ติดตั้ง Microsoft โปรแกรมแก้ไขด่วน947315
• ใช้โปรเซสเซอร์มัลติคอร์ที่แท้จริง (เช่น Intel Core Duo 2 ไม่ใช่ Pentium 4 HT)
• ใช้งานสร้างแบบขนาน 3 แบบ ใน Visual Studio 2005 คุณจะได้พบกับตัวเลือกในเครื่องมือ> ตัวเลือก ... > โครงการและโซลูชั่น> สร้างและเรียกใช้> จำนวนสูงสุดของโครงการสร้างขนาน
• ปิดการใช้งานซอฟแวร์ป้องกันไวรัสของคุณสำหรับ .ilk, .pdb, ซีซี, h ไฟล์และจะตรวจสอบหาไวรัสในการปรับเปลี่ยน ปิดการสแกนไดเร็กทอรีที่แหล่งข้อมูลของคุณอยู่ อย่าทำอะไรโง่ ๆ
• จัดเก็บและสร้างโค้ด Chromium ในฮาร์ดไดรฟ์ตัวที่สอง มันจะไม่เร่งความเร็วในการสร้าง แต่อย่างน้อยคอมพิวเตอร์ของคุณจะยังคงตอบสนองต่อเมื่อคุณทำการซิงค์ gclient หรือบิลด์
• จัดเรียงข้อมูลในฮาร์ดไดรฟ์ของคุณเป็นประจำ
• ปิดใช้งานหน่วยความจำเสมือน

เรามีเกือบ 100 โครงการในโซลูชันเดียวและใช้เวลาสร้างนักพัฒนาเพียงไม่กี่วินาที :)

สำหรับการพัฒนาท้องถิ่นสร้างเราได้สร้าง Visual Studio Addin ว่าการเปลี่ยนแปลงProject referencesไปDLL referencesและ unloads โครงการที่ไม่พึงประสงค์ (และตัวเลือกที่จะเปลี่ยนพวกเขากลับมาแน่นอน)

• สร้างโซลูชันทั้งหมดของเราครั้งเดียว
• ยกเลิกการโหลดโปรเจ็กต์ที่เราไม่ได้กำลังดำเนินการอยู่และเปลี่ยนการอ้างอิงโปรเจ็กต์ทั้งหมดเป็นการอ้างอิง DLL
• ก่อนเช็คอินเปลี่ยนการอ้างอิงทั้งหมดกลับจาก DLL เป็นการอ้างอิงโครงการ

ตอนนี้งานสร้างของเราใช้เวลาเพียงไม่กี่วินาทีเมื่อเรากำลังดำเนินการเพียงไม่กี่โครงการในแต่ละครั้ง นอกจากนี้เรายังสามารถดีบักโปรเจ็กต์เพิ่มเติมได้เมื่อเชื่อมโยงกับ DLL ที่ดีบัก โดยทั่วไปเครื่องมือจะใช้เวลา 10-30 วินาทีในการเปลี่ยนแปลงจำนวนมาก แต่คุณไม่จำเป็นต้องทำบ่อยขนาดนั้น

อัปเดตพฤษภาคม 2558

ข้อตกลงที่ฉันทำ (ในความคิดเห็นด้านล่าง) คือฉันจะปล่อยปลั๊กอินไปยัง Open Source หากได้รับความสนใจเพียงพอ 4 ปีต่อมามีเพียง 44 โหวต (ขณะนี้ Visual Studio มีสองเวอร์ชันถัดมา) ดังนั้นในปัจจุบันจึงเป็นโครงการที่มีลำดับความสำคัญต่ำ

ฉันมีปัญหาคล้าย ๆ กันกับโซลูชัน 21 โครงการและ 1/2 ล้าน LOC ความแตกต่างที่ใหญ่ที่สุดคือการได้รับฮาร์ดไดรฟ์ที่เร็วขึ้น จากการตรวจสอบประสิทธิภาพ "Avg. Disk Queue 'จะเพิ่มขึ้นอย่างมากบนแล็ปท็อปที่ระบุว่าฮาร์ดไดรฟ์คือคอขวด

นี่คือข้อมูลบางส่วนสำหรับเวลาสร้างใหม่ทั้งหมด ...

1) แล็ปท็อป Core 2 Duo 2GHz, 5400 RPM Drive (ไม่แน่ใจแคชเป็นมาตรฐาน Dell inspiron)

สร้างเวลาใหม่ = 112 วินาที

2) เดสก์ท็อป (ปัญหามาตรฐาน), Core 2 Duo 2.3Ghz, แคช 7200RPM ไดรฟ์เดี่ยว 8MB

สร้างเวลาใหม่ = 72 วินาที

3) เดสก์ท็อป Core 2 Duo 3Ghz เดี่ยว 10,000 RPM WD Raptor

สร้างเวลาใหม่ = 39 วินาที

ไม่สามารถระบุไดรฟ์ 10,000 RPM ได้ สร้างที่เร็วกว่าอย่างเห็นได้ชัดบวกกับสิ่งอื่น ๆ เช่นการแสดงเอกสารโดยใช้ file explorer นั้นเร็วกว่าอย่างเห็นได้ชัด เป็นการเพิ่มประสิทธิภาพการทำงานครั้งใหญ่โดยการเร่งวงจรการสร้างโค้ด

เมื่อพิจารณาถึงสิ่งที่ บริษัท ใช้จ่ายไปกับเงินเดือนของนักพัฒนามันเป็นเรื่องบ้ามากที่พวกเขาสามารถเสียเงินซื้อได้โดยติดตั้งพีซีเครื่องเดียวกับที่พนักงานต้อนรับใช้

สำหรับ C # .NET สร้างคุณสามารถใช้.NET ปีศาจ เป็นผลิตภัณฑ์ที่ใช้เหนือกระบวนการสร้าง Visual Studio เพื่อให้เร็วขึ้น

ทำได้โดยการวิเคราะห์การเปลี่ยนแปลงที่คุณทำและสร้างเฉพาะโครงการที่คุณเปลี่ยนแปลงจริงรวมถึงโครงการอื่น ๆ ที่อาศัยการเปลี่ยนแปลงที่คุณทำขึ้นจริง ซึ่งหมายความว่าหากคุณเปลี่ยนรหัสภายในเพียงโครงการเดียวเท่านั้นที่ต้องสร้าง

ปิดโปรแกรมป้องกันไวรัสของคุณ เป็นการเพิ่มอายุให้กับเวลาในการคอมไพล์

ใช้การรวบรวมแบบกระจาย Xoreax IncrediBuildสามารถลดเวลาในการรวบรวมลงเหลือไม่กี่นาที

ฉันใช้มันกับโซลูชัน C \ C ++ ขนาดใหญ่ซึ่งโดยปกติจะใช้เวลา 5-6 ชั่วโมงในการรวบรวม IncrediBuild ช่วยลดเวลานี้เหลือ 15 นาที

คำแนะนำในการลดเวลาคอมไพล์ Visual Studio ของคุณให้เหลือไม่กี่วินาที

Visual Studio ไม่ฉลาดพอที่จะแยกแยะการเปลี่ยนแปลงอินเทอร์เฟซของแอสเซมบลีจากการเปลี่ยนแปลงเนื้อหาโค้ดที่ไม่สำคัญ ความจริงข้อนี้เมื่อรวมเข้ากับโซลูชันที่พันกันขนาดใหญ่บางครั้งสามารถสร้างพายุที่สมบูรณ์แบบของ 'งานสร้างเต็มรูปแบบ' ที่ไม่ต้องการได้เกือบทุกครั้งที่คุณเปลี่ยนรหัสบรรทัดเดียว

กลยุทธ์ในการเอาชนะสิ่งนี้คือการปิดใช้งานการสร้างแผนผังอ้างอิงอัตโนมัติ ในการดำเนินการนี้ให้ใช้ 'ตัวจัดการการกำหนดค่า' (ตัวจัดการการสร้าง / ตัวจัดการการกำหนดค่า ... จากนั้นในดรอปดาวน์การกำหนดค่าโซลูชันที่ใช้งานอยู่ให้เลือก 'ใหม่') เพื่อสร้างการกำหนดค่าการสร้างใหม่ที่เรียกว่า 'ManualCompile' ที่คัดลอกมาจากการกำหนดค่าการแก้ปัญหา อย่าเลือกช่องทำเครื่องหมาย "สร้างการกำหนดค่าโครงการใหม่" ในการกำหนดค่ารุ่นใหม่นี้ให้ยกเลิกการเลือกทุกโครงการเพื่อไม่ให้สร้างขึ้นโดยอัตโนมัติ บันทึกการกำหนดค่านี้โดยกดปุ่ม 'ปิด' การกำหนดค่าการสร้างใหม่นี้ถูกเพิ่มลงในไฟล์โซลูชันของคุณ

คุณสามารถเปลี่ยนจากการกำหนดค่าการสร้างหนึ่งไปเป็นอีกรายการหนึ่งผ่านทางรายการแบบเลื่อนลงการกำหนดค่าการสร้างที่ด้านบนสุดของหน้าจอ IDE ของคุณ (รายการที่มักจะแสดง "การแก้ปัญหา" หรือ "รุ่น") การกำหนดค่าการสร้าง ManualCompile ใหม่นี้อย่างมีประสิทธิภาพจะทำให้ตัวเลือกเมนู Build สำหรับ: 'Build Solution' หรือ 'Rebuild Solution' ไม่มีประโยชน์ ดังนั้นเมื่อคุณอยู่ในโหมด ManualCompile คุณต้องสร้างแต่ละโปรเจ็กต์ที่คุณกำลังแก้ไขด้วยตนเองซึ่งสามารถทำได้โดยคลิกขวาที่โปรเจ็กต์ที่ได้รับผลกระทบแต่ละโปรเจ็กต์ใน Solution Explorer จากนั้นเลือก 'สร้าง' หรือ 'สร้างใหม่' คุณควรจะเห็นว่าเวลาคอมไพล์โดยรวมของคุณตอนนี้เหลือเพียงไม่กี่วินาที

เพื่อให้กลยุทธ์นี้ใช้งานได้จำเป็นสำหรับ VersionNumber ที่พบในไฟล์ AssemblyInfo และ GlobalAssemblyInfo จะยังคงอยู่ในเครื่องของผู้พัฒนา (ไม่ใช่ระหว่างรุ่นที่วางจำหน่ายแน่นอน) และคุณไม่ได้ลงนาม DLL ของคุณ

ความเสี่ยงที่อาจเกิดขึ้นจากการใช้กลยุทธ์ ManualCompile นี้คือนักพัฒนาอาจลืมรวบรวมโปรเจ็กต์ที่จำเป็นและเมื่อพวกเขาเริ่มการดีบั๊กพวกเขาจะได้ผลลัพธ์ที่ไม่คาดคิด (ไม่สามารถแนบดีบักเกอร์ไม่พบไฟล์ ฯลฯ ) เพื่อหลีกเลี่ยงปัญหานี้ควรใช้การกำหนดค่าบิวด์ 'ดีบัก' เพื่อรวบรวมความพยายามในการเข้ารหัสที่มากขึ้นและใช้เฉพาะคอนฟิกูเรชันบิลด์ ManualCompile ระหว่างการทดสอบหน่วยหรือเพื่อทำการเปลี่ยนแปลงอย่างรวดเร็วที่มีขอบเขต จำกัด

หากนี่คือ C หรือ C ++ และคุณไม่ได้ใช้ส่วนหัวที่คอมไพล์ไว้ล่วงหน้าคุณควรเป็น

เรามีโครงการมากกว่า 80 โครงการในโซลูชันหลักของเราซึ่งใช้เวลาประมาณ 4 ถึง 6 นาทีในการสร้างขึ้นอยู่กับประเภทของเครื่องจักรที่นักพัฒนากำลังทำงานอยู่ เราคิดว่ามันนานเกินไปสำหรับการทดสอบทุกครั้งมันกิน FTE ของคุณไปจริงๆ

แล้วจะได้เวลาสร้างเร็วขึ้นได้อย่างไร? อย่างที่คุณทราบกันดีอยู่แล้วว่ามีจำนวนโปรเจ็กต์ที่ทำร้ายเวลาในการสร้างมาก แน่นอนว่าเราไม่ต้องการกำจัดโปรเจ็กต์ทั้งหมดของเราและเพียงแค่โยนไฟล์ต้นฉบับทั้งหมดลงในไฟล์เดียว แต่เรามีโครงการบางอย่างที่สามารถรวมเข้าด้วยกันได้: เนื่องจาก "Repository project" ทุกโครงการในโซลูชันมีโปรเจ็กต์ที่เป็นเอกภาพที่สุดของตัวเองเราจึงรวมโปรเจ็กต์ที่ไม่เหมือนกันทั้งหมดเข้าด้วยกันเป็นโปรเจ็กต์เดียวระดับโลก ซึ่งช่วยลดจำนวนโครงการที่มีประมาณ 12 โครงการและประหยัดเวลาในการสร้างโซลูชันทั้งหมดได้ถึง 40%

เรากำลังคิดหาวิธีแก้ปัญหาอื่น

คุณได้ลองตั้งค่าโซลูชันใหม่ (ที่สอง) ด้วยโปรเจ็กต์ใหม่แล้วหรือยัง? วิธีที่สองนี้ควรรวมไฟล์ทั้งหมดโดยใช้โฟลเดอร์โซลูชัน เนื่องจากคุณอาจประหลาดใจที่เห็นเวลาสร้างของโซลูชันใหม่ที่มีเพียงโครงการเดียว

อย่างไรก็ตามการทำงานกับโซลูชันที่แตกต่างกันสองแบบจะต้องพิจารณาอย่างรอบคอบ นักพัฒนาอาจมีแนวโน้มที่จะทำงานจริง - ในโซลูชันที่สองและละเลยข้อแรกไปโดยสิ้นเชิง เนื่องจากโซลูชันแรกที่มีโปรเจ็กต์กว่า 70 โปรเจ็กต์จะเป็นโซลูชันที่ดูแลลำดับชั้นอ็อบเจ็กต์ของคุณนี่จึงควรเป็นโซลูชันที่บิลด์เซิร์ฟเวอร์ของคุณควรรัน unittests ทั้งหมดของคุณ ดังนั้นเซิร์ฟเวอร์สำหรับการรวมอย่างต่อเนื่องต้องเป็นโครงการ / โซลูชันแรก คุณต้องรักษาลำดับชั้นของวัตถุไว้ใช่

โซลูชันที่สองที่มีเพียงโครงการเดียว (ซึ่งจะสร้าง mucho ได้เร็วกว่า) จะเป็นโครงการที่นักพัฒนาทุกคนจะทำการทดสอบและแก้ไขข้อบกพร่อง คุณต้องดูแลพวกเขาดูที่ buildserver! หากมีสิ่งใดแตกหักจะต้องได้รับการแก้ไข

ตรวจสอบให้แน่ใจว่าการอ้างอิงของคุณเป็นการอ้างอิงโครงการไม่ใช่โดยตรงไปยัง DLL ในไดเรกทอรีเอาต์พุตของไลบรารี

นอกจากนี้กำหนดให้สิ่งเหล่านี้ไม่คัดลอกในเครื่องยกเว้นในกรณีที่จำเป็นจริงๆ (โปรเจ็กต์ EXE หลัก)

ฉันโพสต์คำตอบนี้ แต่เดิมที่นี่: /programming/8440/visual-studio-optimizations#8473 คุณสามารถค้นหาคำแนะนำที่เป็นประโยชน์อื่น ๆ อีกมากมายในหน้านั้น

ถ้าคุณใช้ Visual Studio 2008 คุณสามารถคอมไพล์โดยใช้แฟล็ก / MP เพื่อสร้างโปรเจ็กต์เดียวแบบขนาน ฉันได้อ่านพบว่านี่เป็นคุณลักษณะที่ไม่มีเอกสารใน Visual Studio 2005 แต่ยังไม่เคยลองด้วยตัวเอง

คุณสามารถสร้างหลายโปรเจ็กต์พร้อมกันได้โดยใช้แฟล็ก / M แต่โดยปกติแล้วจะถูกตั้งค่าเป็นจำนวนคอร์ที่มีอยู่ในเครื่องแม้ว่าจะใช้กับ VC ++ เท่านั้น

ฉันสังเกตว่าคำถามนี้เก่า แต่หัวข้อนี้ยังคงเป็นที่สนใจในปัจจุบัน ปัญหาเดียวกันกับฉันเมื่อเร็ว ๆ นี้และสองสิ่งที่ปรับปรุงประสิทธิภาพการสร้างมากที่สุดคือ (1) ใช้ดิสก์เฉพาะ (และเร็ว) สำหรับการคอมไพล์และ (2) ใช้โฟลเดอร์เอาต์พุตเดียวกันสำหรับทุกโปรเจ็กต์และตั้งค่า CopyLocal เป็น False ในโปรเจ็กต์ การอ้างอิง.

แหล่งข้อมูลเพิ่มเติมบางส่วน:

• /programming/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

เครื่องมือวิเคราะห์บางอย่าง:

tools-> options-> การตั้งค่าโปรเจ็กต์ VC ++ -> Build Timing = ใช่จะบอกเวลาสร้างสำหรับทุกๆ vcproj

เพิ่ม/Btสวิตช์ไปที่บรรทัดคำสั่งคอมไพเลอร์เพื่อดูว่าไฟล์ CPP ทุกไฟล์ใช้เวลาเท่าใด

ใช้/showIncludesเพื่อจับการรวมที่ซ้อนกัน (ไฟล์ส่วนหัวที่มีไฟล์ส่วนหัวอื่น ๆ ) และดูว่าไฟล์ใดสามารถบันทึก IO ได้มากโดยใช้การประกาศไปข้างหน้า

สิ่งนี้จะช่วยคุณเพิ่มประสิทธิภาพการทำงานของคอมไพเลอร์โดยการกำจัดการพึ่งพาและการทำงานของหมู

ก่อนที่จะทุ่มเงินเพื่อลงทุนในฮาร์ดไดรฟ์ที่เร็วขึ้นให้ลองสร้างโปรเจ็กต์ของคุณทั้งหมดบนดิสก์ RAM (สมมติว่าคุณมี RAM เหลืออยู่) คุณสามารถค้นหาไดรเวอร์ดิสก์ RAM ว่างต่างๆได้จากอินเทอร์เน็ต คุณจะไม่พบไดรฟ์จริงรวมถึง SSD ที่เร็วกว่าดิสก์ RAM

ในกรณีของฉันโครงการที่ใช้เวลา 5 นาทีในการสร้างบน i7 6-core บนไดรฟ์ 7200 RPM SATA พร้อม Incredibuild ลดลงเพียงประมาณ 15 วินาทีโดยใช้ดิสก์ RAM เมื่อพิจารณาถึงความจำเป็นในการคัดลอกไปยังที่จัดเก็บข้อมูลถาวรและโอกาสในการทำงานที่สูญหาย 15 วินาทีนั้นไม่เพียงพอที่จะจูงใจให้ใช้ดิสก์ RAM และอาจไม่มีแรงจูงใจมากนักที่จะจ่ายเงินหลายร้อยดอลลาร์ในไดรฟ์ที่มี RPM สูงหรือ SSD

การได้รับเล็กน้อยอาจบ่งชี้ว่าการสร้างนั้นถูกผูกไว้กับ CPU หรือการแคชไฟล์ของ Windows นั้นค่อนข้างมีประสิทธิภาพ แต่เนื่องจากการทดสอบทั้งสองเสร็จสิ้นจากสถานะที่ไฟล์ไม่ได้ถูกแคชฉันจึงเอนเอียงไปที่คอมไพล์ที่เชื่อมต่อกับ CPU

ขึ้นอยู่กับรหัสจริงที่คุณรวบรวมระยะทางของคุณอาจแตกต่างกันไปดังนั้นอย่าลังเลที่จะทดสอบ

ไดเร็กทอรีบิวด์ของคุณใหญ่แค่ไหนหลังจากสร้างบิลด์เสร็จสมบูรณ์ หากคุณยึดติดกับการตั้งค่าเริ่มต้นทุกแอสเซมบลีที่คุณสร้างจะคัดลอก DLL ทั้งหมดของการอ้างอิงและการอ้างอิงของการอ้างอิง ฯลฯ ไปยังไดเร็กทอรี bin ในงานก่อนหน้าของฉันเมื่อทำงานกับโซลูชัน ~ 40 โปรเจ็กต์เพื่อนร่วมงานของฉันค้นพบว่าส่วนที่แพงที่สุดของกระบวนการสร้างคือการคัดลอกแอสเซมบลีเหล่านี้ซ้ำแล้วซ้ำอีกและบิลด์หนึ่งสามารถสร้างสำเนาของ DLL เดียวกันในระดับกิกะไบต์และ ครั้งแล้วครั้งเล่า.

ต่อไปนี้เป็นคำแนะนำที่เป็นประโยชน์จาก Patrick Smacchia ผู้เขียน 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

ฉันมีโปรเจ็กต์ที่มี exes, libs และ dlls 120 รายการขึ้นไปและใช้เวลาสร้างนานพอสมควร ฉันใช้โครงสร้างของไฟล์แบตช์ที่เรียกสร้างไฟล์จากไฟล์แบตช์หลักหนึ่งไฟล์ ฉันมีปัญหากับสิ่งแปลก ๆ จากส่วนหัวที่เพิ่มขึ้น (หรือเป็นเรื่องเจ้าอารมณ์) ในอดีตดังนั้นฉันจึงหลีกเลี่ยงสิ่งเหล่านี้ในตอนนี้ ฉันสร้างงานเต็มรูปแบบไม่บ่อยนักและโดยปกติจะปล่อยไว้จนจบวันในขณะที่ฉันเดินเล่นเป็นเวลาหนึ่งชั่วโมง (ฉันเดาได้ว่าใช้เวลาประมาณครึ่งชั่วโมงเท่านั้น) ฉันจึงเข้าใจว่าเหตุใดจึงใช้งานและทดสอบไม่ได้

สำหรับการทำงานและการทดสอบฉันมีไฟล์แบตช์อีกชุดสำหรับแต่ละแอป (หรือโมดูลหรือไลบรารี) ซึ่งมีการตั้งค่าการดีบักทั้งหมดอยู่ด้วย - แต่สิ่งเหล่านี้ยังคงเรียกไฟล์ make เดียวกัน ฉันอาจเปิดปิด DEBUG เป็นครั้งคราวและยังตัดสินใจเกี่ยวกับการสร้างหรือการสร้างหรือถ้าฉันต้องการสร้าง libs ที่โมดูลอาจขึ้นอยู่ด้วยเป็นต้น

ไฟล์แบตช์ยังคัดลอกผลลัพธ์ที่เสร็จสมบูรณ์ไปยังโฟลเดอร์ทดสอบ (หรือหลายโฟลเดอร์) ขึ้นอยู่กับการตั้งค่าซึ่งจะเสร็จสิ้นในไม่กี่วินาทีถึงหนึ่งนาที (ตรงข้ามกับการพูดครึ่งชั่วโมง)

ฉันใช้ IDE (Zeus) ที่แตกต่างกันเนื่องจากฉันต้องการควบคุมสิ่งต่างๆเช่นไฟล์. rc และชอบที่จะรวบรวมจากบรรทัดคำสั่งแม้ว่าฉันจะใช้ MS compliers

ยินดีที่จะโพสต์ตัวอย่างไฟล์แบตช์นี้หากใครสนใจ

ปิดใช้งานการสร้างดัชนีระบบไฟล์บนไดเร็กทอรีต้นทางของคุณ (โดยเฉพาะไดเร็กทอรี obj หากคุณต้องการให้ซอร์สของคุณค้นหาได้)

หากนี่เป็นเว็บแอปการตั้งค่า batch build เป็น true สามารถช่วยได้ขึ้นอยู่กับสถานการณ์

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

คุณสามารถดูภาพรวมได้ที่นี่: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

คุณอาจต้องการตรวจสอบการอ้างอิงโครงการแบบวงกลม มันเป็นปัญหาสำหรับฉันครั้งหนึ่ง

นั่นคือ:

โครงการ A อ้างอิงโครงการ B

โครงการ B อ้างอิงโครงการ C

โครงการ C อ้างอิงโครงการก

ทางเลือกหนึ่งที่ถูกกว่าสำหรับ Xoreax IB คือการใช้สิ่งที่ฉันเรียกว่า uber-file builds โดยพื้นฐานแล้วเป็นไฟล์. cpp ที่มีไฟล์

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

จากนั้นคุณรวบรวมหน่วย uber แทนแต่ละโมดูล เราเห็นเวลาในการคอมไพล์ตั้งแต่ 10-15 นาทีจนถึง 1-2 นาที คุณอาจต้องลองใช้จำนวน #includes ต่อ uber ที่เหมาะสม ขึ้นอยู่กับโครงการต่างๆ ฯลฯ บางทีคุณอาจรวม 10 ไฟล์อาจจะเป็น 20

คุณต้องเสียค่าใช้จ่ายดังนั้นระวัง:

1. คุณไม่สามารถคลิกขวาที่ไฟล์และพูดว่า "compile ... " ได้เนื่องจากคุณต้องแยกไฟล์ cpp แต่ละไฟล์ออกจากบิลด์และรวมเฉพาะไฟล์ uber cpp
2. คุณต้องระวังความขัดแย้งของตัวแปรส่วนกลางแบบคงที่
3. เมื่อคุณเพิ่มโมดูลใหม่คุณต้องปรับปรุงไฟล์ uber ให้ทันสมัยอยู่เสมอ

มันเป็นความเจ็บปวด แต่สำหรับโครงการที่ส่วนใหญ่คงที่ในแง่ของโมดูลใหม่ความเจ็บปวดภายในอาจคุ้มค่า ฉันเคยเห็นวิธีนี้เอาชนะ IB ในบางกรณี

หากเป็นโปรเจ็กต์ C ++ คุณควรใช้ส่วนหัวที่คอมไพล์ไว้ล่วงหน้า สิ่งนี้สร้างความแตกต่างอย่างมากในเวลาคอมไพล์ ไม่แน่ใจว่า cl.exe กำลังทำอะไรอยู่จริงๆ (โดยไม่ใช้ส่วนหัวที่คอมไพล์ไว้ล่วงหน้า) ดูเหมือนว่าจะมองหาส่วนหัว STL จำนวนมากในตำแหน่งที่ไม่ถูกต้องทั้งหมดก่อนที่จะไปยังตำแหน่งที่ถูกต้องในที่สุด ซึ่งจะเพิ่มทั้งวินาทีให้กับไฟล์. cpp ทุกไฟล์ที่กำลังคอมไพล์ ไม่แน่ใจว่านี่เป็นข้อบกพร่องของ cl.exe หรือปัญหา STL บางประเภทใน VS2008

ดูเครื่องที่คุณกำลังสร้างมันได้รับการกำหนดค่าอย่างเหมาะสมที่สุดหรือไม่?

เราเพิ่งมีเวลาสร้างสำหรับผลิตภัณฑ์ระดับองค์กร C ++ ที่ใหญ่ที่สุดของเราลดลงจาก19 ชั่วโมงเป็น16 นาทีโดยตรวจสอบให้แน่ใจว่าได้ติดตั้งไดรเวอร์ตัวกรอง SATA ที่ถูกต้องแล้ว

บอบบาง.

มีสวิตช์ / MP ที่ไม่มีเอกสารใน Visual Studio 2005 โปรดดูที่http://lahsiv.net/blog/?p=40ซึ่งจะเปิดใช้งานการคอมไพล์แบบขนานบนพื้นฐานของไฟล์แทนที่จะเป็นแบบโปรเจ็กต์ สิ่งนี้อาจเร่งการรวบรวมโปรเจ็กต์สุดท้ายหรือถ้าคุณรวบรวมโปรเจ็กต์เดียว

เมื่อเลือก CPU: ขนาดแคช L1 ดูเหมือนจะมีผลอย่างมากต่อเวลาในการคอมไพล์ นอกจากนี้โดยปกติแล้วควรมี 2 คอร์ที่รวดเร็วมากกว่า 4 คอร์ที่ช้า Visual Studio ไม่ได้ใช้คอร์พิเศษอย่างมีประสิทธิภาพ (ฉันใช้สิ่งนี้จากประสบการณ์ของฉันกับคอมไพเลอร์ C ++ แต่อาจเป็นจริงสำหรับ C # one ด้วย)

ตอนนี้ฉันมั่นใจว่า VS2008 มีปัญหา ฉันใช้งานบนแล็ปท็อป Intel dual core พร้อม 3G Ram โดยปิดการป้องกันไวรัส การคอมไพล์โซลูชันมักจะค่อนข้างลื่น แต่ถ้าฉันได้รับการดีบักการคอมไพล์ที่ตามมามักจะทำให้การรวบรวมข้อมูลช้าลง เห็นได้ชัดจากไฟหลักของดิสก์ที่ต่อเนื่องว่ามีคอขวดของดิสก์ I / O (คุณสามารถได้ยินได้เช่นกัน) ถ้าฉันยกเลิกการสร้างและปิด VS กิจกรรมของดิสก์จะหยุดลง รีสตาร์ท VS โหลดโซลูชันใหม่แล้วสร้างใหม่และเร็วกว่ามาก ยูนิตในครั้งต่อไป

ความคิดของฉันคือปัญหานี้เป็นปัญหาการแบ่งหน้าหน่วยความจำ - VS เพิ่งหมดหน่วยความจำและ O / S เริ่มการสลับหน้าเพื่อพยายามเพิ่มพื้นที่ แต่ VS ต้องการมากกว่าการสลับหน้าจะสามารถส่งมอบได้ดังนั้นจึงช้าลงในการรวบรวมข้อมูล นึกคำอธิบายอื่นไม่ออก

VS ไม่ใช่เครื่องมือ RAD ใช่หรือไม่?

บริษัท ของคุณใช้ Entrust สำหรับโซลูชัน PKI / Encryption โดยบังเอิญหรือไม่? ปรากฎว่าเรามีประสิทธิภาพการสร้างที่ยอดเยี่ยมสำหรับเว็บไซต์ขนาดใหญ่ที่สร้างขึ้นใน C # โดยใช้เวลามากกว่า 7 นาทีในการสร้างใหม่ทั้งหมด

เครื่องของฉันเป็น i7-3770 ที่มีแรม 16GB และ SSD 512GB ดังนั้นประสิทธิภาพจึงไม่น่าจะแย่ขนาดนั้น ฉันสังเกตว่าเวลาในการสร้างของฉันเร็วขึ้นอย่างมากในเครื่องรองรุ่นเก่าที่สร้างโค้ดเบสเดียวกัน ดังนั้นฉันจึงยิง ProcMon บนทั้งสองเครื่องทำโปรไฟล์งานสร้างและเปรียบเทียบผลลัพธ์

ดูเถิดเครื่องที่ทำงานช้ามีข้อแตกต่างอย่างหนึ่งนั่นคือการอ้างอิงถึง Entrust.dll ใน stacktrace โดยใช้ข้อมูลที่ได้มาใหม่ผมยังคงค้นหาและพบ StackOverflow นี้: MSBUILD (VS2010) ช้ามากในบางเครื่อง ตามคำตอบที่ยอมรับปัญหาอยู่ในข้อเท็จจริงที่ตัวจัดการ Entrust กำลังประมวลผลการตรวจสอบใบรับรอง. NET แทนที่จะเป็นตัวจัดการ Microsoft ดั้งเดิม Tt ยังแนะนำว่า Entrust v10 แก้ปัญหานี้ที่แพร่หลายใน Entrust 9

ฉันยังมีมันถอนการติดตั้งและการสร้างครั้งของฉันลดลงไป24 วินาที YYMV กับจำนวนโครงการที่คุณกำลังสร้างอยู่และอาจไม่ได้กล่าวถึงปัญหาการปรับขนาดที่คุณสอบถามโดยตรง ฉันจะโพสต์การแก้ไขคำตอบนี้หากฉันสามารถแก้ไขได้โดยไม่ต้องใช้การถอนการติดตั้งซอฟต์แวร์

แน่ใจว่ามีปัญหากับ VS2008 เพราะสิ่งเดียวที่ฉันทำคือติดตั้ง VS2008 เพื่ออัปเกรดโปรเจ็กต์ของฉันซึ่งสร้างด้วย VS2005 ฉันมีเพียง 2 โครงการในโซลูชันของฉัน มันไม่ใหญ่ การรวบรวมด้วย VS2005: 30 วินาทีการรวบรวมด้วย VS2008: 5 นาที

คำแนะนำที่ดีที่ช่วยได้จนถึงตอนนี้ (ไม่ได้บอกว่าไม่มีคำแนะนำที่ดีอื่น ๆ ด้านล่างหากคุณกำลังมีปัญหาฉันขอแนะนำให้อ่านสิ่งที่ช่วยเราได้)

• แล็ปท็อป 3GHz รุ่นใหม่ - พลังของการใช้ประโยชน์ที่หายไปจะทำงานได้อย่างมหัศจรรย์เมื่อต้องรับมือกับการจัดการ
• ปิดใช้งานโปรแกรมป้องกันไวรัสระหว่างการคอมไพล์
• 'ตัดการเชื่อมต่อ' จาก VSS (จริงๆแล้วคือเครือข่าย) ในระหว่างการคอมไพล์ - ฉันอาจให้เราลบการรวม VS-VSS ทั้งหมดและยึดติดกับการใช้ VSS UI

ยังไม่ฉีกขาดผ่านการคอมไพล์ แต่ทุกบิตช่วยได้

นอกจากนี้เรายังทดสอบแนวทางปฏิบัติในการสร้างพื้นที่ใหม่ของแอปพลิเคชันในโซลูชันใหม่โดยนำเข้าใน dll ล่าสุดตามความต้องการซึ่งรวมเข้ากับโซลูชันขนาดใหญ่เมื่อเราพอใจกับสิ่งเหล่านี้

เราอาจทำเช่นเดียวกันกับโค้ดที่มีอยู่โดยการสร้างโซลูชันชั่วคราวที่เพียงแค่ห่อหุ้มส่วนที่เราต้องดำเนินการแล้วทิ้งไปหลังจากที่รวมโค้ดใหม่ เราจำเป็นต้องชั่งน้ำหนักเวลาที่จะรวมรหัสนี้ใหม่กับเวลาที่เราได้รับจากการไม่มี Rip Van Winkle เหมือนกับประสบการณ์ที่มีการคอมไพล์ใหม่อย่างรวดเร็วในระหว่างการพัฒนา

Orion กล่าวถึงในความคิดเห็นว่ายาชื่อสามัญอาจมีส่วนร่วมด้วย จากการทดสอบของฉันดูเหมือนว่าจะได้รับผลกระทบด้านประสิทธิภาพเพียงเล็กน้อย แต่ไม่สูงพอที่จะแน่ใจได้ - เวลาในการคอมไพล์อาจไม่สอดคล้องกันเนื่องจากกิจกรรมของดิสก์ เนื่องจากข้อ จำกัด ด้านเวลาการทดสอบของฉันจึงไม่ได้รวม Generics หรือโค้ดมากเท่าที่จะปรากฏในระบบที่ใช้งานจริงดังนั้นจึงอาจสะสมได้ ฉันจะไม่หลีกเลี่ยงการใช้ยาชื่อสามัญในที่ที่ควรใช้เพียงเพื่อรวบรวมประสิทธิภาพของเวลา