เหตุใดเวลารวบรวมของ Swift จึงช้ามาก

ฉันใช้ Xcode 6 Beta 6

นี่เป็นบางสิ่งบางอย่างที่ดักฟังฉันมาระยะหนึ่งแล้ว แต่มันมาถึงจุดที่ใช้งานได้แทบจะไม่แล้วในตอนนี้

โครงการของฉันเริ่มที่จะมีดีขนาด 65 ไฟล์อย่างรวดเร็วและไม่กี่สะพานไฟล์ Objective-C (ซึ่งจริงๆไม่ได้เป็นสาเหตุของปัญหา)

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

หลังจากการตรวจสอบที่ลึกกว่านี้ฉันพบว่าสิ่งที่ใช้เวลาในการรวบรวม 100% นั้นเป็นCompileSwiftขั้นตอนที่ Xcode ใช้swiftcคำสั่งในไฟล์ Swift ทั้งหมดของเป้าหมายของคุณ

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

ขณะนี้มีไฟล์ต้นฉบับเพียง 65 ไฟล์จึงใช้เวลารวบรวมประมาณ 8/10 วินาทีในแต่ละครั้ง ไม่เร็วมากเลย

ฉันไม่ได้เห็นโพสต์พูดคุยเกี่ยวกับปัญหานี้ยกเว้นคนนี้แต่มันเป็นรุ่นเก่า Xcode 6. ดังนั้นฉันสงสัยว่าถ้าผมเป็นเพียงหนึ่งในกรณีที่

UPDATE

ฉันได้ตรวจสอบโครงการ Swift สองสามรายการบนGitHubเช่นAlamofire , EulerและCryptoSwiftแต่ไม่มีโครงการใดที่มีไฟล์ Swift เพียงพอที่จะเปรียบเทียบได้จริง โครงการเดียวที่ฉันพบว่าเริ่มต้นมีขนาดที่เหมาะสมคือSwiftHNและถึงแม้ว่าจะมีไฟล์ต้นฉบับเพียงโหลเท่านั้นที่ฉันยังสามารถตรวจสอบสิ่งเดียวกันได้พื้นที่เดียวที่เรียบง่ายและโครงการทั้งหมดต้องการการคอมไพล์ใหม่ซึ่งเริ่มใช้ เวลาเล็กน้อย (2/3 วินาที)

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

อัปเดตด้วย Xcode 6 Beta 7

ยังไม่มีการปรับปรุงใด ๆ นี่เป็นการเริ่มที่จะไร้สาระ ด้วยการขาด#importใน Swift ฉันไม่เห็นจริง ๆ ว่า Apple จะสามารถเพิ่มประสิทธิภาพนี้ได้อย่างไร

อัปเดตด้วย Xcode 6.3 และ Swift 1.2

Apple ได้เพิ่มบิลด์ที่เพิ่มขึ้น (และการเพิ่มประสิทธิภาพคอมไพเลอร์อื่น ๆ อีกมากมาย) คุณต้องโยกย้ายรหัสของคุณไปที่ Swift 1.2 เพื่อดูประโยชน์เหล่านั้น แต่ Apple ได้เพิ่มเครื่องมือใน Xcode 6.3 เพื่อช่วยให้คุณทำเช่นนั้น:

อย่างไรก็ตาม

อย่าชื่นชมยินดีอย่างที่ฉันเป็น ตัวแก้กราฟที่ใช้ในการสร้างส่วนเพิ่มนั้นยังไม่ได้รับการปรับอย่างเหมาะสม

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

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

class FileA: NSObject {
    var foo:String?
}
class FileB: NSObject {
    var bar:FileA?
}
class FileC: NSObject {
    var baz:FileB?
}

ตอนนี้ถ้าคุณแก้ไขFileAคอมไพเลอร์จะทำเครื่องหมายว่าFileAจะคอมไพล์ใหม่ มันจะทำการคอมไพล์อีกครั้งFileB(นั่นก็โอเคตามการเปลี่ยนแปลงFileA) แต่ก็FileCเพราะFileBคอมไพล์ใหม่และนั่นก็แย่มากเพราะFileCไม่เคยใช้FileAที่นี่

ดังนั้นฉันจึงหวังว่าพวกเขาจะปรับปรุงตัวแก้ต้นไม้ที่พึ่งพา ... ฉันเปิดเรดาร์ด้วยรหัสตัวอย่างนี้

อัปเดตด้วย Xcode 7 beta 5 และ Swift 2.0

เมื่อวานนี้ Apple เปิดตัวเบต้า 5 และภายในบันทึกประจำรุ่นที่เราได้เห็น:

Swift Language & Compiler •การต่อเติมที่เพิ่มขึ้น: การเปลี่ยนเฉพาะส่วนของฟังก์ชั่นไม่ควรทำให้ไฟล์ที่ต้องพึ่งพาถูกสร้างใหม่อีกต่อไป (15352929)

ฉันได้ลองแล้วและฉันต้องบอกว่ามันใช้งานได้จริง (จริง ๆ !) ตอนนี้ พวกเขาปรับการสร้างที่เพิ่มขึ้นอย่างรวดเร็ว

ฉันขอแนะนำให้คุณสร้างswift2.0สาขาและทำให้รหัสของคุณทันสมัยโดยใช้ XCode 7 เบต้า 5 คุณจะพอใจกับการปรับปรุงคอมไพเลอร์

อัพเดทด้วย Xcode 8.2

เป็นเวลานานแล้วตั้งแต่การอัพเดทครั้งล่าสุดของฉันเกี่ยวกับปัญหานี้

ตอนนี้แอพของเรามีโค้ด Swift เกือบ 20 บรรทัดเกือบสมบูรณ์แล้ว แต่ไม่ได้โดดเด่น มันเปลี่ยนไปอย่างรวดเร็ว 2 และมากกว่าการโยกย้าย 3 อย่างรวดเร็ว ใช้เวลาประมาณ 5 / 6m ในการคอมไพล์ในกลางปี ​​2014 Macbook pro (2.5 GHz Intel Core i7) ซึ่งไม่เป็นปัญหาสำหรับโครงสร้างที่สะอาด

อย่างไรก็ตามการสร้างที่เพิ่มขึ้นยังคงเป็นเรื่องตลกแม้ Apple จะอ้างว่า:

Xcode จะไม่สร้างเป้าหมายใหม่ทั้งหมดเมื่อมีการเปลี่ยนแปลงเพียงเล็กน้อยเท่านั้นที่เกิดขึ้น (28892475)

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

ฉันต้องการจะชี้ให้คุณไปที่หัวข้อนี้ในฟอรัมนักพัฒนาของ Apple ซึ่งมีข้อมูลเพิ่มเติมเกี่ยวกับปัญหา (รวมทั้งชื่นชมการสื่อสารของ Apple dev ในเรื่องนี้เป็นระยะ ๆ )

โดยทั่วไปผู้คนจะคิดขึ้นมาสองสามสิ่งเพื่อพยายามปรับปรุงการสร้างที่เพิ่มขึ้น:

1. เพิ่มการHEADER_MAP_USES_VFSตั้งค่าโครงการเป็นtrue
2. ปิดใช้งานFind implicit dependenciesจากโครงร่างของคุณ
3. สร้างโครงการใหม่และย้ายลำดับชั้นไฟล์ของคุณไปยังโครงการใหม่

ฉันจะลองโซลูชันที่ 3 แต่วิธีที่ 1/2 ไม่ได้ผลสำหรับเรา

สิ่งที่แดกดันในสถานการณ์ทั้งหมดนี้คือการดูโพสต์แรกในปัญหานี้เราใช้ Xcode 6 ด้วยฉันเชื่อว่ารหัส swift 1 หรือ swift 1.1 เมื่อเรามาถึงการรวบรวมความซบเซาแรกและตอนนี้ประมาณสองปีต่อมาแม้จะมีการปรับปรุงจริงจาก Apple สถานการณ์เลวร้ายอย่างที่เคยเป็นกับ Xcode 6 วิธีที่น่าขัน

ที่จริงผมจริงๆเสียใจเลือกสวิฟท์กว่า Obj / C สำหรับโครงการของเราเพราะแห้วทุกวันมันเกี่ยวข้องกับ (ฉันยังเปลี่ยนเป็น AppCode แต่เป็นอีกเรื่องหนึ่ง)

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

หากคุณมีเวลา (และความกล้าหาญ!) ฉันเดาว่า Apple ยินดีต้อนรับเรดาร์เกี่ยวกับเรื่องนี้

ครั้งต่อไป! ไชโย

อัปเดตด้วย Xcode 9

สะดุดเมื่อนี้ในวันนี้ Xcode เปิดตัวระบบสร้างใหม่อย่างเงียบ ๆ เพื่อปรับปรุงประสิทธิภาพการทำงานอันยิ่งใหญ่ในปัจจุบัน คุณต้องเปิดใช้งานผ่านการตั้งค่าพื้นที่ทำงาน

ได้ลองแล้ว แต่จะอัปเดตโพสต์นี้หลังจากเสร็จสิ้น ดูเหมือนว่าจะมีแนวโน้ม

มันกลับกลายเป็นว่า Rob Napier พูดถูก มันเป็นหนึ่งไฟล์เดียว (อันที่จริงวิธีหนึ่ง) ที่ทำให้คอมไพเลอร์ไป berzek

ตอนนี้อย่าเข้าใจฉันผิด Swift ทำการคอมไพล์ไฟล์ของคุณใหม่ทุกครั้ง แต่สิ่งที่ยอดเยี่ยมในตอนนี้คือ Apple ได้เพิ่มข้อเสนอแนะการคอมไพล์แบบเรียลไทม์ผ่านไฟล์ที่คอมไพล์ดังนั้น Xcode 6 GM จะแสดงไฟล์ Swift ที่รวบรวมและสถานะการคอมไพล์แบบเรียลไทม์ อย่างที่คุณเห็นในภาพหน้าจอนี้:

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

var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
        "url" : self.url?.absoluteString ?? "",
        "title" : self.title ?? ""
        ])

return dic.copy() as NSDictionary

เพราะทรัพย์สินที่titleเป็นของประเภทและไม่ได้var title:String? คอมไพเลอร์กำลังจะบ้าเมื่อมีการเพิ่มไปยังNSStringNSMutableDictionary

เปลี่ยนเป็น:

var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
        "url" : self.url?.absoluteString ?? "",
        "title" : NSString(string: self.title ?? "")
        ])

return dic.copy() as NSDictionary

ทำให้การรวบรวมเริ่มตั้งแต่ 10/15 วินาที (อาจมากกว่า) จนถึงวินาทีเดียว ... น่าทึ่ง

เราได้ลองบางสิ่งบางอย่างเพื่อต่อสู้กับสิ่งนี้เนื่องจากเรามีรหัส Swift ประมาณ 100k บรรทัดและรหัส ObjC 300k บรรทัด

ขั้นตอนแรกของเราคือการเพิ่มประสิทธิภาพฟังก์ชั่นทั้งหมดตามฟังก์ชั่นการรวบรวมเวลาการส่งออก (เช่นอธิบายไว้ที่นี่https://thatthinginswift.com/debug-long-compile-times-swift/ )

ต่อไปเราเขียนสคริปต์เพื่อรวมไฟล์ swift ทั้งหมดไว้ในไฟล์เดียวซึ่งจะแบ่งระดับการเข้าถึง แต่มันใช้เวลารวบรวมจาก 5-6 นาทีถึง ~ 1 นาที

ตอนนี้หมดอายุเพราะเราถาม Apple เกี่ยวกับเรื่องนี้และพวกเขาแนะนำว่าเราควรทำสิ่งต่อไปนี้:

1. เปิด 'การเพิ่มประสิทธิภาพทั้งโมดูล' ในการตั้งค่าการสร้าง 'Swift Compiler - Code Generation' เลือก'Fast, Whole Module Optimization'

2. ใน 'Swift Compiler - Custom Flags' สำหรับการพัฒนาของคุณให้เพิ่ม '-Onone'

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการปรับแต่งโมดูลทั้งหมดดูโพสต์บล็อกของ Apple ที่นี่ - https://swift.org/blog/whole-module-optimizations/

เราพบว่าการตั้งค่าเหล่านี้อนุญาตให้รวบรวมรหัส Swift ของเราใน 30 วินาที :-) ฉันไม่มีหลักฐานว่ามันจะทำงานกับโครงการอื่น ๆ ได้อย่างไร

หมายเหตุสำหรับการสร้าง App Store ของคุณคุณควรปล่อยให้'-Onone'สถานะออกเนื่องจากการเพิ่มประสิทธิภาพจะแนะนำสำหรับการสร้างการผลิต

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

เป็นตัวอย่างของประเภทของรหัสที่อาจทำให้เกิดปัญหาส่วนสำคัญ 38 บรรทัดนี้ใช้เวลามากกว่าหนึ่งนาทีในการรวบรวมใน beta7 ทั้งหมดนี้เกิดจากบล็อกนี้:

let pipeResult =
seq |> filter~~ { $0 % 2 == 0 }
  |> sorted~~ { $1 < $0 }
  |> map~~ { $0.description }
  |> joinedWithCommas

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

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

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

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

นี่คือตัวอย่างคำสั่งที่ควรทำเคล็ดลับ:

xctool -workspace <your_workspace> -scheme <your_scheme> -jobs 1 build

ผลลัพธ์ของเฟส "ไฟล์ Compile Swift" จะเป็นดังนี้:

...
   ✓ Compile EntityObserver.swift (1623 ms)
   ✓ Compile Session.swift (1526 ms)
   ✓ Compile SearchComposer.swift (1556 ms)
...

จากผลลัพธ์นี้คุณสามารถระบุได้อย่างรวดเร็วว่าไฟล์ใดที่ใช้เวลานานกว่าไฟล์อื่น ๆ ในการรวบรวม ยิ่งไปกว่านั้นคุณสามารถกำหนดด้วยความแม่นยำสูงว่า refactorings ของคุณ (cast ที่ชัดเจนคำแนะนำประเภท ฯลฯ ... ) ลดเวลาในการคอมไพล์สำหรับไฟล์เฉพาะหรือไม่

หมายเหตุ: ในทางเทคนิคคุณสามารถทำได้ด้วยเช่นกันxcodebuildแต่เอาต์พุตนั้นละเอียดอย่างเหลือเชื่อและกินยาก

ในกรณีของฉัน Xcode 7 ไม่มีความแตกต่างเลย ฉันมีฟังก์ชั่นหลายอย่างที่ต้องใช้เวลาหลายวินาทีในการรวบรวม

ตัวอย่าง

// Build time: 5238.3ms
return CGSize(width: size.width + (rightView?.bounds.width ?? 0) + (leftView?.bounds.width ?? 0) + 22, height: bounds.height)

หลังจากแกะ optionals เวลาสร้างลดลง99.4%

// Build time: 32.4ms
var padding: CGFloat = 22
if let rightView = rightView {
    padding += rightView.bounds.width
}

if let leftView = leftView {
    padding += leftView.bounds.width
}
return CGSizeMake(size.width + padding, bounds.height)

ดูตัวอย่างเพิ่มเติมในโพสต์นี้และโพสต์นี้

Build Time Analyzer สำหรับ Xcode

ฉันพัฒนาปลั๊กอิน Xcodeซึ่งอาจมีประโยชน์สำหรับทุกคนที่ประสบปัญหาเหล่านี้

ดูเหมือนว่าจะมีการปรับปรุงใน Swift 3 ดังนั้นหวังว่าเราจะเห็นการรวบรวมโค้ด Swift ของเราเร็วขึ้น

อาจเป็นไปได้ว่าเราไม่สามารถแก้ไข Swift compiler ได้ แต่สิ่งที่เราสามารถแก้ไขได้คือรหัสของเรา!

มีตัวเลือกที่ซ่อนอยู่ในคอมไพเลอร์ Swift ที่พิมพ์ช่วงเวลาที่แน่นอนที่คอมไพเลอร์ใช้ในการรวบรวมทุกฟังก์ชั่นเดียว: -Xfrontend -debug-time-function-bodies. มันช่วยให้เราสามารถค้นหาคอขวดในรหัสของเราและปรับปรุงเวลารวบรวมอย่างมีนัยสำคัญ

รันสิ่งต่อไปนี้ในเทอร์มินัลและวิเคราะห์ผลลัพธ์:

xcodebuild -workspace App.xcworkspace -scheme App clean build OTHER_SWIFT_FLAGS="-Xfrontend -debug-time-function-bodies" | grep [1-9].[0-9]ms | sort -nr > culprits.txt

น่ากลัวไบรอัน iRace เขียนบทความเกี่ยวกับเรื่องที่ยอดเยี่ยมProfiling Swift รวบรวมครั้งของคุณ

การแก้ปัญหาคือการหล่อ

ฉันมีพจนานุกรมจำนวนมากมากมายเช่นนี้

["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
.....

ใช้เวลารวบรวมประมาณ 40 นาที จนกระทั่งฉันหล่อพจนานุกรมเช่นนี้:

["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
....

สิ่งนี้ทำงานได้เกือบทุกปัญหาที่ฉันพบเกี่ยวกับประเภทข้อมูลที่ฉันเขียนลงในแอปพลิเคชันของฉันอย่างหนัก

สิ่งหนึ่งที่ควรทราบก็คือเครื่องยนต์อนุมานประเภท Swift นั้นช้ามากกับประเภทซ้อนกัน คุณสามารถรับแนวคิดทั่วไปเกี่ยวกับสิ่งที่ทำให้เกิดความเชื่องช้าโดยการดูบันทึกการสร้างสำหรับแต่ละหน่วยการรวบรวมที่ใช้เวลานานแล้วคัดลอก & วางคำสั่ง Xcode-spawned แบบเต็มไปยังหน้าต่างเทอร์มินัลแล้วกด CTRL- \ เพื่อรับ การวินิจฉัยบางอย่าง ลองดูที่http://blog.impathic.com/post/99647568844/debugging-slow-swift-compile-timesสำหรับตัวอย่างแบบเต็ม

ตรวจสอบให้แน่ใจด้วยว่าเมื่อรวบรวมการดีบัก (Swift หรือ Objective-C) คุณต้องตั้งค่าเป็น Build Active Architecture เท่านั้น:

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

ก่อนอื่นการเปรียบเทียบ Objective-C กับ Swift compiler นั้นโหดร้ายอย่างใด Swift ยังอยู่ในช่วงเบต้าและฉันมั่นใจว่า Apple กำลังทำงานในการจัดหาฟังก์ชั่นและแก้ไขข้อผิดพลาดมากกว่าให้ความเร็วสูง (คุณไม่ได้เริ่มสร้างบ้านด้วยการซื้อเฟอร์นิเจอร์) ฉันเดาว่า Apple จะปรับให้เหมาะสมที่สุดในเวลาที่เหมาะสม

ถ้าด้วยเหตุผลบางอย่างไฟล์ต้นฉบับทั้งหมดจะต้องถูกคอมไพล์เสร็จสมบูรณ์ตัวเลือกอาจจะสร้างโมดูล / ไลบรารีที่แยกจากกัน แต่ตัวเลือกนี้ยังไม่สามารถทำได้เนื่องจาก Swift ไม่สามารถอนุญาตห้องสมุดได้จนกว่าภาษาจะเสถียร

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

เพียงแค่คาดเดา แต่สำหรับ Apple เท่านั้นที่รู้ ...

สำหรับ Xcode 8 ไปที่การตั้งค่าโครงการจากนั้นแก้ไข> เพิ่มการตั้งค่าการสร้าง> เพิ่มการตั้งค่าที่ผู้ใช้กำหนดและเพิ่มรายการต่อไปนี้:

SWIFT_WHOLE_MODULE_OPTIMIZATION = YES

การเพิ่มการตั้งค่าสถานะนี้ทำให้เวลาในการรวบรวมของเราสะอาดลดลงจาก 7 นาทีเป็น 65 วินาทีสำหรับโครงการ 40KLOC ที่รวดเร็วอย่างน่าอัศจรรย์ นอกจากนี้ยังสามารถยืนยันว่าเพื่อน 2 คนได้เห็นการปรับปรุงที่คล้ายกันในโครงการขององค์กร

ฉันสามารถสันนิษฐานได้ว่านี่เป็นข้อบกพร่องบางอย่างใน Xcode 8.0

แก้ไข: ดูเหมือนจะไม่ทำงานอีกต่อไปใน Xcode 8.3 สำหรับบางคน

น่าเสียดายที่คอมไพเลอร์ Swift ยังไม่ได้รับการปรับปรุงเพื่อการรวบรวมที่รวดเร็วและเพิ่มขึ้น (ตั้งแต่ Xcode 6.3 เบต้า) ในขณะเดียวกันคุณสามารถใช้เทคนิคต่อไปนี้เพื่อปรับปรุงเวลารวบรวมของ Swift:

• แยกแอปออกเป็น Frameworks เพื่อลดผลกระทบของการคอมไพล์ซ้ำ แต่ระวังว่าคุณต้องหลีกเลี่ยงการพึ่งพาแบบวนซ้ำในแอปของคุณ สำหรับข้อมูลละเอียดเพิ่มเติมเกี่ยวกับหัวข้อนี้ตรวจสอบโพสต์นี้: http://bits.citrusbyte.com/improving-swift-compile-time/

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

• ลองฉีดรหัสรันไทม์ด้วย 'Injection for Xcode'

• ใช้วิธีการ roopc: http://roopc.net/posts/2014/speeding-up-swift-builds/

• บรรเทากลไกการอนุมานแบบรวดเร็วโดยให้คำแนะนำบางอย่างด้วยการปลดเปลื้องที่ชัดเจน

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

var a = ["a": "b",
         "c": "d",
         "e": "f",
         "g": "h",
         "i": "j",
         "k": "l",
         "m": "n",
         "o": "p",
         "q": "r",
         "s": "t",
         "u": "v",
         "x": "z"]

อาจเป็นสาเหตุที่ควรแก้ไข:

var a = NSMutableDictionary()
a["a"] = "b"
a["c"] = "d"
... and so on

สำหรับการดีบักและทดสอบตรวจสอบให้แน่ใจว่าใช้การตั้งค่าต่อไปนี้เพื่อลดเวลาในการรวบรวมจากประมาณ 20 นาทีเหลือน้อยกว่า 2 นาที

1. ในการตั้งค่าการสร้างโครงการให้ค้นหา "การเพิ่มประสิทธิภาพ" เปลี่ยนดีบั๊กเป็น "เร็วที่สุด [-O3]" หรือสูงกว่า
2. ตั้งค่า Build สำหรับสถาปัตยกรรมที่ใช้งานอยู่: ใช่
3. รูปแบบข้อมูลการดีบัก: DWARF
4. การเพิ่มประสิทธิภาพโมดูลทั้งหมด: NO

ฉันเสียเวลานับไม่ถ้วนในการรอคอยที่โครงการจะสร้างเพียงเพื่อตระหนักว่าฉันต้องทำการเปลี่ยนแปลงเล็กน้อยและต้องรออีก 30 นาทีเพื่อทดสอบ นี่คือการตั้งค่าที่เหมาะกับฉัน (ฉันยังทดลองกับการตั้งค่า)

แต่อย่างน้อยคุณควรตั้ง "DWARF with dSYM" (ถ้าคุณต้องการตรวจสอบแอปพลิเคชันของคุณ) และสร้าง Active สถาปัตยกรรมเป็น "ไม่" สำหรับการปล่อย / การเก็บถาวรเพื่อผลักดันไปยัง iTunes Connect (ฉันจำได้ว่า

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

หากคุณมีฟังก์ชั่นล่ามโซ่เรียกเช่น

let sum = [1,2,3].map({String($0)}).flatMap({Float($0)}).reduce(0, combine: +)

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

let numbers: [Int] = [1,2,3]
let strings: [String] = sum.map({String($0)})
let floats: [Float] = strings.flatMap({Float($0)})
let sum: Float = floats.reduce(0, combine: +)

โดยเฉพาะอย่างยิ่งสำหรับชนิดของตัวเลขCGFloat, Intก็สามารถช่วยได้มาก ตัวเลขที่แท้จริงเช่น2สามารถแสดงประเภทตัวเลขที่แตกต่างกัน ดังนั้นคอมไพเลอร์ต้องคิดออกจากบริบทที่เป็นหนึ่ง

+ควรหลีกเลี่ยงฟังก์ชั่นที่ใช้เวลานานในการค้นหา การใช้หลาย ๆ อย่าง+เพื่อต่อหลาย ๆ อาเรย์นั้นช้าเพราะคอมไพเลอร์จำเป็นต้องรู้ว่าการใช้งานแบบ+ใดที่ควรถูกเรียกใช้สำหรับแต่ละ+อัน ดังนั้นใช้var a: [Foo]กับappend()แทนถ้าเป็นไปได้

คุณสามารถเพิ่มคำเตือนในการตรวจสอบซึ่งฟังก์ชั่นจะช้าในการรวบรวมใน Xcode

ในBuild Settingsสำหรับการค้นหาเป้าหมายของคุณสำหรับOther Swift Flagsและเพิ่ม

-Xfrontend -warn-long-function-bodies=100

เพื่อเตือนสำหรับทุกฟังก์ชั่นที่ใช้เวลานานกว่า 100 ms ในการคอมไพล์

สำหรับโครงการที่ผสม Objective-C และรหัส Swift, เราสามารถตั้งค่าใน-enable-bridging-pch Other Swift Flagsด้วยวิธีนี้การเชื่อมโยงส่วนหัวจะถูกวิเคราะห์คำเพียงครั้งเดียวและผลลัพธ์ (ไฟล์ "ส่วนหัว precompiled" หรือ "PCH" ชั่วคราว) จะถูกแคชและนำมาใช้ใหม่ในไฟล์ Swift ทั้งหมดในเป้าหมาย Apple อ้างว่ามันลดเวลาในการสร้างลง 30% ลิงค์อ้างอิง:

หมายเหตุ: ใช้งานได้กับ Swift 3.1 ขึ้นไปเท่านั้น

การรีบูตเครื่อง Mac ของฉันทำสิ่งมหัศจรรย์สำหรับปัญหานี้ ฉันไปจาก 15 นาทีงานสร้างถึง 30 วินาทีงานสร้างเพียงแค่รีบูตเครื่อง

Swift compile time ได้รับการปรับปรุงใน Xcode 6.3 ใหม่

การปรับปรุงคอมไพเลอร์

คอมไพเลอร์ Swift 1.2 ได้รับการออกแบบให้มีเสถียรภาพมากขึ้นและปรับปรุงประสิทธิภาพในทุกด้าน การเปลี่ยนแปลงเหล่านี้ยังมอบประสบการณ์ที่ดีขึ้นเมื่อทำงานกับ Swift ใน Xcode การปรับปรุงที่มองเห็นได้มากที่สุด ได้แก่ :

งานสร้างที่เพิ่มขึ้น

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

executables ที่เร็วขึ้น

Debug builds สร้างไบนารีที่รันเร็วกว่ามากและการปรับแต่งใหม่ให้ประสิทธิภาพการทำงานรีลีสที่ดียิ่งขึ้น

การวินิจฉัยคอมไพเลอร์ที่ดีขึ้น

ข้อผิดพลาดที่ชัดเจนและข้อความเตือนพร้อมกับการแก้ไขใหม่ทำให้ง่ายต่อการเขียนรหัส Swift 1.2 ที่เหมาะสม

การปรับปรุงเสถียรภาพ

คอมไพเลอร์ล่มส่วนใหญ่ได้รับการแก้ไขแล้ว คุณควรเห็นคำเตือน SourceKit น้อยลงในเครื่องมือแก้ไข Xcode

นี่เป็นอีกกรณีหนึ่งที่สามารถทำให้เกิดการชะลอตัวอย่างมากด้วยการอนุมานประเภท ผู้ประกอบการหลอมรวม

การเปลี่ยนบรรทัดเช่น:

abs(some_optional_variable ?? 0)

ถึง

abs((some_optional_variable ?? 0) as VARIABLE_TYPE)

ช่วยนำเวลารวบรวมของฉันมาตั้งแต่ 70s ถึง 13s

ไม่มีอะไรทำงานให้ฉันใน Xcode 6.3.1 - เมื่อฉันเพิ่ม arround 100 Swift ไฟล์ Xcode แขวนคอแบบสุ่มในการสร้างและ / หรือการจัดทำดัชนี ฉันลองตัวเลือกแบบแยกส่วนที่ไม่ประสบความสำเร็จ

การติดตั้งและใช้งาน Xcode 6.4 Betaใช้งานได้จริงสำหรับฉัน

นี่เป็นเวทย์มนตร์สำหรับฉัน - Speed ​​Up Swift Compilationรวบรวม มันลดเวลาในการรวบรวมเป็น 3 นาทีจาก 10 นาที

มันบอกว่าคุณควรเปิดในWhole Module Optimizationขณะที่เพิ่ม-Ononeเข้าOther Swift Flagsมา

ฉันใช้Swift 3บนXcode 8.3Xcode 8.2 /

การผสมตัวอักษรจำนวนเต็มและลอยตามตัวอักษรในการแสดงออกหนึ่งยังทำให้เวลารวบรวม

1.0 + (1.0 + (1  * (1.0 + 1.0))) // 3429ms

1.0 + (1.0 + (1.0  * (1.0 + 1.0))) // 5ms

นิพจน์เวลาคอมไพล์ 1000 + ms จำนวนมากลดลงเหลือ 10 ~ 100ms หลังจากฉันใส่.0จำนวนเต็มตามตัวอักษร