วิธีจัดการกับปัญหาการคอมไพล์โค้ดฐานขนาดใหญ่?


10

แม้ว่าฉันสามารถเขียนโค้ดได้ แต่ฉันยังไม่มีประสบการณ์ในการทำงานในโครงการขนาดใหญ่ สิ่งที่ฉันทำจนถึงตอนนี้ก็คือการเขียนโปรแกรมขนาดเล็กที่รวบรวมในไม่กี่วินาที (แบบฝึกหัด c / c ++ ต่าง ๆ เช่นอัลกอริทึมหลักการเขียนโปรแกรมแนวคิดแนวความคิดหรือเพียงแค่ลอง api ... ) หรือทำงานในโครงการขนาดเล็กบางโครงการ ทำในภาษาสคริปต์ (python, php, js) โดยไม่จำเป็นต้องรวบรวม

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

เป็นตัวอย่างฉันจะใช้ Wordpress มันค่อนข้างง่ายที่จะลองและคิดวิธีการสร้างปลั๊กอินสำหรับมัน ก่อนอื่นคุณต้องเริ่มต้นด้วยการสร้างปลั๊กอิน "Hello World" อย่างง่ายจากนั้นคุณสร้างอินเทอร์เฟซที่ง่ายสำหรับผู้ดูแลระบบเพื่อทำความคุ้นเคยกับ API จากนั้นคุณสร้างมันขึ้นมาและทำให้สิ่งที่ซับซ้อนมากขึ้นในเวลาที่เปลี่ยนไป ครั้ง .. ความคิดที่จะต้องคอมไพล์บางสิ่งที่ยิ่งใหญ่เท่า WP ซ้ำแล้วซ้ำอีกหลังจากการเปลี่ยนแปลงเล็กน้อยแต่ละครั้งเพื่อลอง "ถ้ามันได้ผล" และ "การทำงาน / รู้สึกอย่างไร" ดูเหมือนจะไม่มีประสิทธิภาพช้าและผิด

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

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

ขอบคุณ


4
Ob XKCDและเสื้อยืด thinkgeek ที่เกี่ยวข้อง* 8 ')
Mark Booth

1
หากคุณทำงานในโครงการที่มีขนาดใหญ่และมีงบประมาณมากพอคุณสามารถสร้างเซิร์ฟเวอร์เพื่อคอมไพล์ให้คุณ :)
SoylentGray

@Chad - ฉันรู้ว่า แต่มันเป็นเพียงบ้านของฉัน GNU / Linux เครื่องเดสก์ทอปและฉันในขณะนี้ :)
pootzko

@Chad Ok คุณบอกเราว่าเราต้องการเซิร์ฟเวอร์เฉพาะเพื่อจัดการกับกลุ่ม Java (หรือภาษาที่รวบรวมอื่น ๆ ) จำนวนมาก? นั่นเป็นอึทั้งหมด
Kolob Canyon

1
@KolobCanyon - ไม่ฉันกำลังบอกว่ามีขนาดที่คุณสามารถทำงานได้ที่จะต้องใช้พวกเขา และตอนนี้พวกเขามีราคาถูกพอที่การมี VM แบบออนดีมานด์เพื่อการรวบรวมที่รวดเร็วและการทดสอบอัตโนมัตินั้นง่ายพอที่เครื่องชั่งจะไม่ใหญ่
SoylentGray

คำตอบ:


8

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

ใน C / C ++ การคอมไพล์ค่อนข้างตรงไปตรงมา คุณคอมไพล์แปลไฟล์ต้นฉบับแต่ละไฟล์เป็นรหัสเครื่อง (เราเรียกมันว่าไฟล์ออบเจ็กต์ * .o) จากนั้นคุณเชื่อมโยงไฟล์ออบเจ็กต์ทั้งหมดของคุณให้เป็นไฟล์ปฏิบัติการขนาดใหญ่หนึ่งไฟล์

เช่นเดียวกับ MainMa ที่กล่าวถึงบางไลบรารีสร้างขึ้นในไฟล์ที่แยกต่างหากซึ่งจะถูกลิงก์แบบไดนามิก ณ รันไทม์กับไฟล์ที่เรียกทำงานได้ ไลบรารีเหล่านี้เรียกว่า Shared Objects (* .so) ใน Unix และ Dynamically Linked Libraries (DLL) ใน Windows ไลบรารีแบบไดนามิกมีข้อดีมากมายซึ่งหนึ่งในนั้นคือคุณไม่จำเป็นต้องคอมไพล์ / ลิงก์พวกมันเว้นแต่ว่าซอร์สโค้ดของมันจะเปลี่ยนไปอย่างมีประสิทธิภาพ

มีเครื่องมือสร้างระบบอัตโนมัติที่ช่วยให้คุณ:

  • ระบุการพึ่งพาระหว่างส่วนต่าง ๆ ของทรีของคุณ
  • เปิดใช้การคอมไพล์แบบตรงเวลาและสุขุมเฉพาะในส่วนที่ได้รับการแก้ไข

สิ่งที่โด่งดังที่สุด (สร้าง, ant, maven, ... ) สามารถตรวจจับโดยอัตโนมัติว่าส่วนใดของรหัสที่มีการเปลี่ยนแปลงตั้งแต่การรวบรวมครั้งสุดท้ายและสิ่งที่วัตถุ / ไบนารีจำเป็นต้องได้รับการปรับปรุง

อย่างไรก็ตามสิ่งนี้มีค่าใช้จ่าย (ค่อนข้างน้อย) ในการเขียน "build script" มันเป็นไฟล์ที่มีข้อมูลทั้งหมดเกี่ยวกับงานสร้างของคุณเช่นการกำหนดเป้าหมายและการอ้างอิงของพวกเขากำหนดว่าคุณต้องการคอมไพเลอร์ใดและตัวเลือกใดที่จะใช้กำหนดสภาพแวดล้อมการสร้างเส้นทางห้องสมุดของคุณ ... คุณอาจได้ยินเกี่ยวกับ Makefiles ทั่วไปในโลก Unix) หรือ build.xml (เป็นที่นิยมในโลก Java) นี่คือสิ่งที่พวกเขาทำ


2
Ant (Java) ไม่สามารถระบุสิ่งที่ต้องการรวบรวมใหม่ มันจัดการกับส่วนที่ไม่สำคัญของงานคอมไพล์ซอร์สโค้ดที่เปลี่ยนแปลงใหม่ แต่ไม่เข้าใจการพึ่งพาคลาสเลย เราพึ่งพา IDEs สำหรับสิ่งนั้นและพวกเขาผิดพลาดหากมีการเปลี่ยนแปลงวิธีการลงลายมือชื่อในแบบที่ไม่ต้องการการเปลี่ยนแปลงรหัสการโทร
วินไคลน์

@kevincline ฉันสองสิ่งนี้ - ANT รวบรวมทุกอย่างเว้นแต่คุณจะระบุสิ่งที่แตกต่างในbuild.xmlไฟล์
Kolob Canyon

7

คุณไม่ต้องคอมไพล์โครงการใหม่ทุกครั้ง ตัวอย่างเช่นถ้าเป็นแอปพลิเคชัน C / C ++ มีโอกาสที่มันจะถูกแยกออกเป็นไลบรารี (DLLs ใน Windows) ทุกไลบรารีจะถูกรวบรวมแยกต่างหาก

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


3
ถ้าฉันไม่คอมไพล์ซ้ำมันทั้งหมดเมื่อไหร่ฉันจะมีเวลาเล่นกับTrebuchet
SoylentGray

5

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

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

การแบ่งโครงการออกเป็นชิ้น ๆ ที่รวบรวมเป็นรายบุคคลช่วยให้บางสิ่งเป็นระเบียบเกิดขึ้น

อาคารที่เพิ่มขึ้น

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

นี้ก่อให้เกิดความคิดของอาคารที่เพิ่มขึ้น เมื่อทำการ build ที่เพิ่มขึ้นเฉพาะชิ้นส่วนที่ได้รับผลกระทบจากการเปลี่ยนแปลงเท่านั้นที่จะคอมไพล์ใหม่ สิ่งนี้จะช่วยเร่งเวลาในการพัฒนาอย่างมาก จริงอยู่คุณอาจยังต้องรอให้ทุกอย่างได้รับการเชื่อมโยงอีกครั้ง แต่ก็ยังประหยัดได้มากกว่าที่จะต้องคอมไพล์ซ้ำและเชื่อมโยงทุกอย่างใหม่ (BTW: ระบบ / ภาษาบางระบบรองรับการเชื่อมโยงที่เพิ่มขึ้นเพื่อให้เฉพาะสิ่งที่เปลี่ยนแปลงต้องได้รับการเชื่อมโยงใหม่ค่าใช้จ่ายนี้มักจะอยู่ในประสิทธิภาพและขนาดของโค้ดที่แย่

การทดสอบหน่วย

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

กรณีที่มีข้อ จำกัด ในการใช้การทดสอบจะเห็นได้ในการทดสอบพัฒนาไดรฟ์ (TDD) ในรูปแบบการพัฒนานี้ไม่มีการเขียน / แก้ไขรหัสเว้นแต่ว่าจะแก้ไขการทดสอบที่ล้มเหลว

ทำให้ง่ายขึ้น

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

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

แต่นั่นก็ยังคงทำให้เข้าใจว่าสิ่งต่าง ๆ เกี่ยวข้องกันอย่างไร นั่นเป็นงานจำนวนมากและอย่างที่ฉันพูดไปก่อนหน้านี้โปรแกรมเมอร์นั้นขี้เกียจ ดังนั้นพวกเขาจึงมีเครื่องมืออีกประเภทหนึ่งขึ้นมา เครื่องมือเหล่านี้ถูกเขียนขึ้นเพื่อพิจารณาการพึ่งพาสำหรับคุณ บ่อยครั้งที่เครื่องมือเป็นส่วนหนึ่งของสภาพแวดล้อมการพัฒนาแบบบูรณาการ (IDE) เช่น Eclipse และ Visual Studio แต่ก็มีบางส่วนที่เป็นแบบสแตนด์อโลนที่ใช้สำหรับแอปพลิเคชันทั่วไปและเฉพาะ (makedep, QMake สำหรับโปรแกรม Qt)

* ที่จริงแล้วโปรแกรมเมอร์ไม่ได้ขี้เกียจพวกเขาต้องการใช้เวลาทำงานกับปัญหาไม่ใช่ทำงานซ้ำ ๆ ที่โปรแกรมสามารถทำงานอัตโนมัติ


5

นี่คือรายการสิ่งของที่คุณสามารถลองเพิ่มความเร็วในการสร้าง C / C ++:

  • คุณตั้งค่าให้สร้างเฉพาะสิ่งที่เปลี่ยนแปลงใหม่หรือไม่ สภาพแวดล้อมส่วนใหญ่ทำสิ่งนี้ตามค่าเริ่มต้น ไม่จำเป็นต้องคอมไพล์ไฟล์อีกครั้งหากไม่มีส่วนหัวใดเปลี่ยนแปลง ในทำนองเดียวกันไม่มีเหตุผลที่จะสร้าง dll / exe ขึ้นใหม่หากลิงก์ทั้งหมดใน objs / lib ยังไม่ได้เปลี่ยน
  • ใส่สิ่งที่บุคคลที่สามที่ไม่เคยเปลี่ยนแปลงและส่วนหัวที่เกี่ยวข้องในบางพื้นที่อ่านรหัสไลบรารีเท่านั้น คุณต้องการเพียงส่วนหัวและไบนารีที่เกี่ยวข้อง คุณไม่จำเป็นต้องสร้างสิ่งนี้จากแหล่งอื่นนอกเหนือจากอาจจะครั้งเดียว
  • เมื่อสร้างใหม่ทุกอย่างทั้งสองปัจจัยที่ จำกัด ในประสบการณ์ของฉันได้รับจำนวนแกนและความเร็วดิสก์ รับ quad-core อ้วน ๆ , เครื่องที่มีเกลียวมากและมี HDD ที่ดีจริงๆและประสิทธิภาพของคุณจะดีขึ้น พิจารณาไดรฟ์ของรัฐที่มั่นคง - โปรดทราบว่าราคาถูกอาจจะเลวร้ายยิ่งกว่าดี hdd พิจารณาใช้การจู่โจมเพื่อเพิ่ม HDD ของคุณ
  • ใช้ระบบการสร้างแบบกระจายเช่นIncredibuildซึ่งจะแยกการรวบรวมข้ามสถานีงานอื่น ๆ ในเครือข่ายของคุณ (ตรวจสอบให้แน่ใจว่าคุณมีเครือข่ายที่มั่นคง)
  • ติดตั้งบิวด์ที่เป็นเอกภาพเพื่อช่วยคุณไม่ให้โหลดไฟล์ส่วนหัวซ้ำ

จากประสบการณ์ของฉัน (ไม่มาก แต่ก็ดี) ความเร็วของดิสก์เริ่มไม่เกี่ยวข้องหากโครงการของคุณมีขนาดเกิน "เล็กมาก" แค่คิดเกี่ยวกับสิ่งที่คุณพูดในหัวข้อย่อยถัดไป: คุณกำลังใช้เครือข่ายเพื่อเพิ่มความเร็วในการรวบรวม หากดิสก์เป็นคอขวดขนาดใหญ่การหันไปใช้เครือข่ายนั้นดูไม่ดีนัก
R. Martinho Fernandes

อีกวิธีที่ประหยัดคือการรวบรวมใน tmpfs สามารถเพิ่มประสิทธิภาพได้อย่างมากหากกระบวนการรวบรวมนั้นผูกไว้กับ IO
Artefact2

4

ความคิดที่จะต้องคอมไพล์บางสิ่งที่ยิ่งใหญ่เท่า WP ซ้ำแล้วซ้ำอีกหลังจากการเปลี่ยนแปลงเล็กน้อยแต่ละครั้งเพื่อลอง "ถ้ามันทำงานได้" และ "วิธีการทำงาน / รู้สึกอย่างไร" ดูเหมือนจะไม่มีประสิทธิภาพช้าและผิด

การดำเนินการบางสิ่งที่ถูกตีความนั้นยังไม่มีประสิทธิภาพและช้าและผิดพลาด คุณกำลังบ่นเกี่ยวกับข้อกำหนดของเวลาบนพีซีของ dev แต่ไม่ได้รวบรวมสาเหตุที่ทำให้ข้อกำหนดของเวลาบนพีซีของผู้ใช้ซึ่งแย่กว่านั้นมาก

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


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

@pootzko: มันค่อนข้างไม่ยุติธรรมเลยที่จะพูดถึงข้อเสียของการคอมไพล์เมื่อคุณไม่ได้พูดถึงข้อเสียของการตีความ
DeadMG

1
ไม่มันไม่ใช่. เป็นอีกการถกเถียงกันและไม่มีอะไรเกี่ยวข้องกับคำถามของฉัน ฉันไม่ได้บอกว่ามันเป็นสิ่งที่ไม่ควรพูดถึง ควร แต่ไม่ใช่ที่นี่
pootzko

@pootzko: จากนั้นคุณไม่ควรอุทิศคำถามส่วนใหญ่เพื่อระบุสิ่งที่คุณไม่ชอบเกี่ยวกับการรวบรวม คุณควรเขียนบางสิ่งที่สั้นลงและประสบความสำเร็จมากขึ้นเช่น "จะลดเวลาการคอมไพล์ของโครงการขนาดใหญ่ได้อย่างไร"
DeadMG

ฉันไม่รู้ว่าฉันต้องถามใครบางคนเกี่ยวกับวิธีที่ฉัน "ควร" ถามคำถามของฉัน .. ? : OI เขียนมันในขณะที่ฉันทำเพื่ออธิบายมุมมองของฉันให้ดีขึ้นเพื่อให้คนอื่นเข้าใจได้ดีขึ้นและอธิบายให้ฉันทราบถึงวิธีการบรรลุสิ่งที่เหมือนกัน / คล้ายคลึงกันด้วยภาษาที่คอมไพล์ ฉันอีกครั้ง - ไม่ได้ - ขอให้ทุกคนบอกฉันว่าภาษาที่แปลทำให้เกิดความต้องการเวลาที่เลวร้ายลงบนพีซีของผู้ใช้หรือไม่ ฉันรู้ว่ามันไม่มีส่วนเกี่ยวข้องกับคำถามของฉัน - "มันทำยังไงกับภาษาที่คอมไพล์แล้ว" ขอโทษ ดูเหมือนว่าคนอื่นจะคิดในสิ่งที่ฉันถามดังนั้นฉันจึงไม่คิดว่าคำถามของฉันจะไม่ชัดเจนพอ ..
pootzko

4
  • สร้างใหม่บางส่วน

หากโปรเจ็กต์ใช้ DAG พึ่งพาการคอมไพล์ที่เหมาะสมคุณสามารถหนีไปได้ด้วยการคอมไพล์ไฟล์อ็อบเจ็กต์ใหม่ที่การเปลี่ยนแปลงของคุณมีผล

  • กระบวนการรวบรวมหลายอย่าง

นอกจากนี้สมมติว่า DAG พึ่งพาการรวบรวมที่เหมาะสมคุณสามารถรวบรวมโดยใช้กระบวนการหลายกระบวนการ หนึ่งงานต่อคอร์ / cpu เป็นบรรทัดฐาน

  • การทดสอบที่ดำเนินการได้

คุณสามารถสร้างไฟล์เรียกทำงานหลายไฟล์สำหรับการทดสอบที่เชื่อมโยงเฉพาะอ็อบเจ็กต์ไฟล์เท่านั้น


2

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

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

โครงการไฟล์ 37,000 รายการของเราใช้เวลารวบรวมประมาณ 15 นาทีก่อนที่จะทำการเปลี่ยนแปลงเหล่านี้ หลังจากการเปลี่ยนแปลงมันถูกลดเหลือ 2-3 นาที

แน่นอนว่ามันคุ้มค่าที่จะกล่าวถึงประเด็นของ MainMa อีกครั้ง อย่าคอมไพล์โครงการใหม่ทุกครั้งที่คุณต้องการเห็นการเปลี่ยนแปลง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.