compilation - स्विफ्ट संकलन समय इतना धीमा क्यों है?




swift (14)

मैं एक्सकोड 6 बीटा 6 का उपयोग कर रहा हूँ।

यह कुछ ऐसा है जो मुझे कुछ समय के लिए परेशान कर रहा है, लेकिन यह उस बिंदु तक पहुंच रहा है जहां यह अब मुश्किल से प्रयोग योग्य है।

मेरी परियोजना में 65 स्विफ्ट फाइलों का एक सभ्य आकार और कुछ ब्रिज ऑब्जेक्टिव-सी फाइलें शुरू हो रही हैं (जो वास्तव में समस्या का कारण नहीं हैं)।

ऐसा लगता है कि किसी भी स्विफ्ट फ़ाइल में किसी भी मामूली संशोधन की तरह लगता है (जैसे कि ऐप में मुश्किल से इस्तेमाल होने वाली कक्षा में एक साधारण सफेद स्थान जोड़ना) पूरे स्विफ्ट फ़ाइलों को निर्दिष्ट लक्ष्य के लिए पुन: संकलित करने का कारण बनता है।

गहन जांच के बाद, मैंने पाया है कि कंपाइलर समय का 100% हिस्सा ले रहा है संकलन CompileSwift चरण है जहां swiftc आपके लक्ष्य की सभी स्विफ्ट फ़ाइलों पर swiftc कमांड चलाता है।

मैंने कुछ और जांच की, और अगर मैं केवल डिफ़ॉल्ट नियंत्रक के साथ ऐप प्रतिनिधि को रखता हूं तो संकलन बहुत तेज़ होता है, लेकिन जब मैं अपनी परियोजना फ़ाइलों में से अधिक से अधिक जोड़ रहा था, तो संकलन समय वास्तव में धीमा हो रहा था।

अब केवल 65 स्रोत फ़ाइलों के साथ, हर बार संकलित करने में लगभग 8/10 सेकंड लगते हैं। बिल्कुल तेज नहीं है।

मैंने इस मुद्दे को छोड़कर इस मुद्दे के बारे में कोई भी पोस्ट नहीं देखी है, लेकिन यह एक्सकोड 6 का पुराना संस्करण था। इसलिए मैं सोच रहा हूं कि मैं उस मामले में एकमात्र हूं।

अद्यतन करें

मैंने Alamofire पर Alamofire , Euler और CryptoSwift जैसे कुछ स्विफ्ट परियोजनाओं की CryptoSwift , लेकिन उनमें से कोई भी वास्तव में तुलना करने के लिए पर्याप्त स्विफ्ट फाइलें नहीं CryptoSwift । एकमात्र प्रोजेक्ट जो मैंने पाया था कि एक सभ्य आकार शुरू हो रहा था SwiftHN था, और भले ही इसमें केवल एक दर्जन स्रोत फाइलें थीं, फिर भी मैं एक ही चीज़ को सत्यापित करने में सक्षम था, एक साधारण स्थान और पूरी परियोजना को पुन: संकलन की आवश्यकता थी जो एक थोड़ा समय (2/3 सेकंड)।

उद्देश्य-सी कोड की तुलना में जहां विश्लेषक और संकलन तेजी से चमक रहे हैं, यह वास्तव में लगता है जैसे स्विफ्ट बड़ी परियोजनाओं को संभालने में सक्षम नहीं होगा, लेकिन कृपया मुझे बताएं कि मैं गलत हूं।

एक्सकोड 6 बीटा 7 के साथ अद्यतन करें

अभी भी कोई सुधार नहीं है। यह हास्यास्पद हो रहा है। स्विफ्ट में #import की कमी के साथ, मैं वास्तव में नहीं देखता कि ऐप्पल कभी भी इसे अनुकूलित करने में सक्षम कैसे होगा।

एक्सकोड 6.3 और स्विफ्ट 1.2 के साथ अद्यतन करें

ऐप्पल ने वृद्धिशील बिल्ड (और कई अन्य कंपाइलर अनुकूलन) जोड़े हैं। उन लाभों को देखने के लिए आपको अपने कोड को स्विफ्ट 1.2 में माइग्रेट करना होगा, लेकिन ऐप्पल ने ऐसा करने में आपकी सहायता के लिए एक्सकोड 6.3 में एक टूल जोड़ा है:

तथापि

जैसा मैंने किया उतना जल्दी आनंद न करें। ग्राफ सॉल्वर जो वे बिल्ड incremental बनाने के लिए उपयोग करते हैं, अभी तक बहुत अच्छी तरह अनुकूलित नहीं है।

दरअसल, यह फ़ंक्शन हस्ताक्षर परिवर्तनों को नहीं देखता है, इसलिए यदि आप एक विधि के ब्लॉक में कोई स्थान जोड़ते हैं, तो उस वर्ग के आधार पर सभी फ़ाइलों को फिर से संकलित किया जाएगा।

दूसरा, ऐसा लगता है कि एक बदलाव उन फ़ाइलों पर आधारित है जो पुन: संकलित किए गए थे, भले ही कोई परिवर्तन उन्हें प्रभावित न करे। उदाहरण के लिए, यदि आप इन तीन वर्गों को विभिन्न फाइलों में ले जाते हैं

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

अब यदि आप FileA संशोधित FileA , तो संकलक स्पष्ट रूप से FileA को पुन: FileA करने के लिए चिह्नित करेगा। यह FileB को भी पुन: FileB करेगा (जो कि FileB में किए गए परिवर्तनों के आधार पर ठीक होगा), लेकिन FileC भी है क्योंकि FileB का पुन: FileB है, और यह बहुत खराब है क्योंकि FileC कभी भी FileA का उपयोग नहीं करता है।

तो मुझे आशा है कि वे उस निर्भरता पेड़ सॉल्वर में सुधार करेंगे ... मैंने इस नमूना कोड के साथ एक radar खोला है।

एक्सकोड 7 बीटा 5 और स्विफ्ट 2.0 के साथ अद्यतन करें

कल ऐप्पल ने बीटा 5 जारी किया और रिलीज नोट्स के अंदर हम देख सकते थे:

स्विफ्ट भाषा और कंपाइलर • वृद्धिशील बनाता है: केवल फ़ंक्शन के शरीर को बदलने से अब निर्भर फ़ाइलों को पुनर्निर्मित नहीं किया जाना चाहिए। (15352929)

मैंने इसे आज़मा दिया है और मुझे कहना होगा कि यह वास्तव में वास्तव में काम कर रहा है (वास्तव में!) अब। उन्होंने तेजी से बढ़ते निर्माण को बहुत अनुकूलित किया।

मैं अत्यधिक अनुशंसा करता हूं कि आप एक swift2.0 शाखा बनाएं और swift2.0 7 बीटा 5 का उपयोग करके अपना कोड अद्यतित रखें। आप संकलक के संवर्द्धन से प्रसन्न होंगे (हालांकि मैं कहूंगा कि एक्सकोड 7 की वैश्विक स्थिति अभी भी धीमी और छोटी है )

एक्सकोड 8.2 के साथ अद्यतन करें

यह इस मुद्दे पर मेरे आखिरी अपडेट के बाद से कुछ समय हो गया है, इसलिए यह यहां है।

हमारा ऐप अब लगभग विशेष रूप से स्विफ्ट कोड की लगभग 20k लाइनें है, जो सभ्य लेकिन उत्कृष्ट नहीं है। यह तेजी से 2 और स्विफ्ट 3 माइग्रेशन से अधिक था। मध्य 2014 मैकबुक समर्थक (2.5 गीगाहर्ट्ज इंटेल कोर i7) पर संकलित करने में लगभग 5/6 मीटर लगते हैं जो एक स्वच्छ निर्माण पर ठीक है।

हालांकि ऐप्पल दावा करते हुए वृद्धिशील बिल्ड अभी भी एक मजाक है कि:

जब केवल छोटे बदलाव हुए हैं तो एक्सकोड पूरे लक्ष्य का पुनर्निर्माण नहीं करेगा। (28892475)

जाहिर है, मुझे लगता है कि हम में से कई लोग इस बकवास की जांच के बाद हँसे (मेरी निजी परियोजना के किसी भी फाइल में एक निजी (निजी!) संपत्ति जोड़ना पूरी चीज को फिर से तैयार करेगा ...)

मैं आपको ऐप्पल डेवलपर मंचों पर इस धागे पर इंगित करना चाहता हूं जिसमें इस मुद्दे के बारे में कुछ और जानकारी है (साथ ही मामले में एक बार मामले पर ऐप्पल देव संचार की सराहना की)

मूल रूप से लोग वृद्धिशील निर्माण में सुधार करने के लिए कुछ चीजों के साथ आ गए हैं:

  1. एक HEADER_MAP_USES_VFS प्रोजेक्ट सेटिंग true सेट करें
  2. अक्षम करें अपनी योजना से Find implicit dependencies
  3. एक नई परियोजना बनाएं और अपनी फाइल पदानुक्रम को नए में ले जाएं।

मैं समाधान 3 का प्रयास करूंगा लेकिन समाधान 1/2 हमारे लिए काम नहीं करेगा।

इस पूरी स्थिति में विडंबनापूर्ण रूप से मजाकिया यह है कि इस मुद्दे पर पहली पोस्ट को देखते हुए हम एक्सकोड 6 का उपयोग कर रहे थे, क्योंकि मुझे लगता है कि मैं पहले संकलन सुस्तता तक पहुंच गया था और अब लगभग दो साल बाद ऐप्पल से वास्तविक सुधार के बावजूद मैं स्विफ्ट 1 या स्विफ्ट 1.1 कोड पर विश्वास करता हूं। स्थिति उतनी ही खराब है जितनी कि यह एक्सकोड 6 के साथ थी। कितना विडंबनापूर्ण।

मुझे वास्तव में हमारे प्रोजेक्ट के लिए ओब्जे / सी पर स्विफ्ट चुनने पर खेद है कि इसमें दैनिक निराशा शामिल है। (मैं ऐपकोड पर भी स्विच करता हूं लेकिन यह एक और कहानी है)

वैसे भी मुझे लगता है कि इस एसओ पोस्ट में 32k + विचार और 143 अप इस लेखन के रूप में हैं, इसलिए मुझे लगता है कि मैं अकेला नहीं हूं। इस स्थिति में निराशावादी होने के बावजूद वहां लोगों को लटकाएं सुरंग के अंत में कुछ प्रकाश हो सकता है।

यदि आपके पास समय है (और साहस!) मुझे लगता है कि ऐप्पल इसके बारे में रडार का स्वागत करता है।

अगली बार टिल! चियर्स

एक्सकोड 9 के साथ अद्यतन करें

आज this पर ठोकरें। एक्सकोड ने चुपचाप वर्तमान भयानक प्रदर्शन में सुधार के लिए एक नया निर्माण प्रणाली शुरू की। आपको वर्कस्पेस सेटिंग्स के माध्यम से इसे सक्षम करना होगा।

अभी तक कोशिश की है लेकिन यह करने के बाद इस पोस्ट को अपडेट कर देगा। यद्यपि आशाजनक लग रहा है।


शायद हम स्विफ्ट कंपाइलर को ठीक नहीं कर सकते हैं, लेकिन कुछ जो हम तय कर सकते हैं वह हमारा कोड है!

स्विफ्ट कंपाइलर में एक छिपी हुई विकल्प है जो सटीक समय अंतराल को प्रिंट करता है जो संकलक प्रत्येक एकल फ़ंक्शन को संकलित करने के लिए लेता है: -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

विस्मयकारी ब्रायन इरेस ने इसके बारे में शानदार लेख लिखा है जो आपके स्विफ्ट संकलन के समय को प्रोफाइल कर रहा है


इसकी संभावना आपके प्रोजेक्ट के आकार के साथ बहुत कम है। यह शायद कोड का कुछ विशिष्ट टुकड़ा है, संभवतः यहां तक ​​कि केवल एक पंक्ति। आप पूरी परियोजना के बजाए एक समय में एक फ़ाइल को संकलित करने की कोशिश करके इसका परीक्षण कर सकते हैं। या यह देखने के लिए कि कौन सी फ़ाइल इतनी लंबी लग रही है, बिल्ड लॉग देखने का प्रयास करें।

कोड के प्रकार के उदाहरण के रूप में जो परेशानी पैदा कर सकता है, यह 38-लाइन गस्ट बीटा 7 में संकलित करने के लिए एक मिनट से अधिक समय लेता है। यह सब एक ब्लॉक के कारण होता है:

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

सरल करें कि केवल एक पंक्ति या दो से और यह लगभग तुरंत संकलित करता है। इस समस्या के बारे में कुछ ऐसा है जो संकलक में घातीय वृद्धि (संभावित रूप से फैक्टोरियल विकास) पैदा कर रहा है। जाहिर है कि यह आदर्श नहीं है, और यदि आप ऐसी परिस्थितियों को अलग कर सकते हैं, तो आपको उन मुद्दों को साफ़ करने में सहायता के लिए रडार खोलना चाहिए।


एक्सकोड 8 के लिए, प्रोजेक्ट सेटिंग्स पर जाएं, फिर संपादक> बिल्ड सेटिंग जोड़ें> उपयोगकर्ता-निर्धारित सेटिंग जोड़ें, और निम्न जोड़ें:

SWIFT_WHOLE_MODULE_OPTIMIZATION = YES

इस झंडे को जोड़ने से हमारे स्वच्छ-निर्माण संकलन के समय को 40 केएलओसी स्विफ्ट प्रोजेक्ट के लिए 7 मिनट से 65 तक घटा दिया गया। यह भी पुष्टि कर सकते हैं कि 2 दोस्तों ने एंटरप्राइज़ प्रोजेक्ट पर समान सुधार देखा है।

मैं केवल यह मान सकता हूं कि यह एक्सकोड 8.0 में किसी प्रकार का बग है

संपादित करें: यह कुछ लोगों के लिए Xcode 8.3 में अब और काम नहीं कर रहा है।


ऑब्जेक्टिव-सी और स्विफ्ट कोड को मिश्रित करने वाली परियोजनाओं के लिए, हम Other Swift Flags में -enable-bridging-pch सेट कर सकते हैं। इसके साथ, ब्रिजिंग हेडर को केवल एक बार पार्स किया जाता है, और परिणाम (एक अस्थायी "प्रीकंपिल्ड हेडर" या "पीसीएच" फ़ाइल) लक्ष्य में सभी स्विफ्ट फ़ाइलों में कैश और पुन: उपयोग किया जाता है। ऐप्पल ने दावा किया कि यह 30% तक निर्माण का समय कम कर देता है। संदर्भ लिंक:

नोट: यह केवल स्विफ्ट 3.1 और ऊपर के लिए काम करता है।


खैर, यह पता चला कि रोब नेपियर सही था। यह एक एकल फ़ाइल थी (वास्तव में एक विधि) जो संकलक को बेरजेक जाने का कारण बना रही थी।

अब मुझे गलत मत समझो। स्विफ्ट हर बार आपकी सभी फाइलों को पुन: संकलित करता है, लेकिन अब बड़ी बात यह है कि ऐप्पल ने संकलित फाइलों पर रीयल-टाइम संकलन प्रतिक्रिया जोड़ दी है, इसलिए एक्सकोड 6 जीएम अब दिखाता है कि कौन सी स्विफ्ट फाइलें संकलित की जा रही हैं और वास्तविक समय में संकलन की स्थिति जैसा कि आप इस स्क्रीनशॉट में देख सकते हैं:

इसलिए यह जानना बहुत आसान है कि आपकी कौन सी फाइलें इतनी लंबी लग रही हैं। मेरे मामले में यह कोड का यह टुकड़ा था:

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

return dic.copy() as NSDictionary

क्योंकि संपत्ति का title प्रकार का title था var title:String? और NSString नहीं। NSMutableDictionary जोड़ते समय संकलक पागल हो रहा था।

इसे बदलना:

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 सेकंड (शायद और भी अधिक) से एक सेकंड तक ... अद्भुत बना दिया।


चूंकि यह सब सामान बीटा में है, और चूंकि स्विफ्ट कंपाइलर (कम से कम आज के रूप में) खुला नहीं है, मुझे लगता है कि आपके प्रश्न का कोई वास्तविक जवाब नहीं है।

सबसे पहले, उद्देश्य-सी से स्विफ्ट कंपाइलर की तुलना किसी भी तरह क्रूर है। स्विफ्ट अभी भी बीटा में है, और मुझे यकीन है कि ऐप्पल बिजली की गति प्रदान करने से अधिक कार्यक्षमता और फिक्सिंग बग प्रदान करने में काम कर रहा है (आप फर्नीचर खरीदने से घर बनाना शुरू नहीं करते हैं)। मुझे लगता है कि एप्पल समय पर संकलक को अनुकूलित करेगा।

अगर किसी कारण से सभी स्रोत फ़ाइलों को पूरी तरह से संकलित किया जाना है, तो एक विकल्प अलग मॉड्यूल / पुस्तकालय बनाने के लिए हो सकता है। लेकिन यह विकल्प अभी तक संभव नहीं है, क्योंकि स्विफ्ट भाषा स्थिर होने तक पुस्तकालयों की अनुमति नहीं दे सकता है।

मेरा अनुमान है कि वे कंपाइलर को अनुकूलित करेंगे। इसी कारण से हम पूर्व-संकलित मॉड्यूल नहीं बना सकते हैं, यह अच्छी तरह से हो सकता है कि कंपाइलर को स्क्रैच से सब कुछ संकलित करने की आवश्यकता है। लेकिन एक बार जब भाषा एक स्थिर संस्करण तक पहुंच जाती है और बाइनरी का प्रारूप अब और नहीं बदल रहा है, तो हम अपने पुस्तकालयों को बनाने में सक्षम होंगे, और शायद (?) संकलक भी अपने काम को अनुकूलित करने में सक्षम होंगे।

बस अनुमान लगाया, हालांकि, केवल ऐप्पल जानता है ...


दुर्भाग्य से, स्विफ्ट कंपाइलर अभी भी तेज और वृद्धिशील संकलन (एक्सकोड 6.3 बीटा के रूप में) के लिए अनुकूलित नहीं है। इस बीच आप स्विफ्ट संकलन समय को बेहतर बनाने के लिए निम्न में से कुछ तकनीकों का उपयोग कर सकते हैं:

  • पुन: संकलन प्रभाव को कम करने के लिए ऐप को फ्रेमवर्क में विभाजित करें। लेकिन ध्यान रखें कि आपको अपने ऐप में चक्रीय निर्भरताओं से बचना चाहिए। इस विषय पर भविष्य की जानकारी के लिए इस पोस्ट की जांच करें: http://bits.citrusbyte.com/improving-swift-compile-time/

  • अपनी परियोजना के कुछ हिस्सों के लिए स्विफ्ट का उपयोग करें जो काफी स्थिर हैं और अक्सर नहीं बदलते हैं। उन अन्य क्षेत्रों के लिए जहां आपको बहुत बार या उन क्षेत्रों को बदलने की आवश्यकता होती है जिनके लिए बहुत अधिक संकलन / रन पुनरावृत्तियों को पूरा करने की आवश्यकता होती है (लगभग किसी भी UI संबंधित सामग्री), मिश्रण-और-मिलान दृष्टिकोण के साथ उद्देश्य-सी का बेहतर उपयोग करें।

  • 'एक्सकोड के लिए इंजेक्शन' के साथ रनटाइम कोड इंजेक्शन आज़माएं

  • Roopc विधि का प्रयोग करें: http://roopc.net/posts/2014/speeding-up-swift-builds/

  • स्पष्ट जानवरों के साथ कुछ संकेत देकर त्वरित प्रकार अनुमान इंजन को राहत दें।


ध्यान देने योग्य बात यह है कि स्विफ्ट प्रकार अनुमान इंजन इंजन नेस्टेड प्रकारों के साथ बहुत धीमा हो सकता है। आप व्यक्तिगत संकलन इकाइयों के लिए बिल्ड लॉग देखकर धीमेपन का कारण बनने के बारे में एक सामान्य विचार प्राप्त कर सकते हैं जो लंबे समय तक ले रहे हैं और फिर पूर्ण एक्सकोड-स्पॉन्ड कमांड को टर्मिनल विंडो में कॉपी और पेस्ट कर रहे हैं और फिर CTRL- \ को प्राप्त करने के लिए कुछ निदान। एक पूर्ण उदाहरण के लिए http://blog.impathic.com/post/99647568844/debugging-slow-swift-compile-times समय पर एक नज़र डालें।


मेरे मैक को रिबूट करने से इस मुद्दे के लिए आश्चर्य हुआ। मैं बस 15 मिनट के निर्माण से 30 सेकंड तक रिबूट करके चला गया।


यदि आप अपने संकलन समय को धीमा करने वाली विशिष्ट फ़ाइलों की पहचान करने की कोशिश कर रहे हैं, तो आप इसे xctool माध्यम से अपनी कमांड लाइन से संकलित करने का प्रयास कर सकते हैं जो आपको फ़ाइल द्वारा संकलित समय फ़ाइल देगा।

ध्यान देने योग्य बात यह है कि, डिफ़ॉल्ट रूप से, यह प्रत्येक सीपीयू कोर के साथ एक साथ 2 फाइलें बनाता है, और आपको "नेट" विलुप्त समय नहीं देगा, लेकिन पूर्ण "उपयोगकर्ता" समय। इस तरह समांतर फाइलों के बीच भी सभी समय और बहुत समान दिखते हैं।

इसे दूर करने के लिए, -jobs ध्वज को 1 पर सेट करें , ताकि यह फ़ाइल निर्माण को समानांतर न करे। इसमें अधिक समय लगेगा, लेकिन अंत में आपके पास "नेट" संकलन समय होगा कि आप फ़ाइल द्वारा फ़ाइल की तुलना कर सकते हैं।

यह एक उदाहरण कमांड है जो चाल करना चाहिए:

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

"संकलन स्विफ्ट फाइल" चरण का उत्पादन कुछ ऐसा होगा:

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

इस आउटपुट से आप जल्दी से पहचान सकते हैं कि कौन सी फाइलें संकलित करने के लिए दूसरों की तुलना में अधिक समय ले रही हैं। इसके अलावा, आप उच्च सटीकता के साथ निर्धारित कर सकते हैं कि क्या आपके रिफैक्टरिंग (स्पष्ट कास्ट, प्रकार संकेत, इत्यादि ...) विशिष्ट फ़ाइलों के लिए संकलन समय कम कर रहे हैं या नहीं।

नोट: तकनीकी रूप से आप इसे xcodebuild साथ भी कर सकते हैं लेकिन आउटपुट अविश्वसनीय रूप से वर्बोज़ और उपभोग करने में मुश्किल है।


यह मेरे लिए जादू की तरह काम कर रहा है - स्पीड अप स्विफ्ट संकलन । यह संकलन समय 10 मिनट से 3 मिनट तक कम कर दिया।

यह कहता है कि आपको Other Swift Flags में जोड़ने के दौरान Whole Module Optimization को चालू करना चाहिए।

मैं Xcode 8.3 / Xcode 8.2 पर Swift 3 का उपयोग कर रहा हूं।


यहां एक और मामला है जो प्रकार के अनुमान के साथ भारी मंदी का कारण बन सकता है। ऑपरेटरों ऑपरेटरों

लाइनों को बदलना जैसे:

abs(some_optional_variable ?? 0)

सेवा मेरे

abs((some_optional_variable ?? 0) as VARIABLE_TYPE)

70 के दशक से 13 के दशक तक मेरा संकलन समय लाने में मदद मिली


स्विफ्ट सरणी और शब्दकोश निर्माण इस के लिए एक बहुत लोकप्रिय कारण प्रतीत होता है (विशेष रूप से आपके लिए जो Ruby पृष्ठभूमि से आते हैं), यानी,

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

हमने इसका मुकाबला करने के लिए कुछ चीजों की कोशिश की है क्योंकि हमारे पास स्विफ्ट कोड की लगभग 100k लाइनें और ओबीजेसी कोड की 300k लाइनें हैं।

हमारा पहला कदम फ़ंक्शन संकलन समय आउटपुट के अनुसार सभी कार्यों को अनुकूलित करना था (उदाहरण के लिए यहां बताया गया है https://thatthinginswift.com/debug-long-compile-times-swift/ )

इसके बाद हमने सभी स्विफ्ट फ़ाइलों को एक फ़ाइल में विलय करने के लिए एक स्क्रिप्ट लिखी, यह पहुंच स्तर को तोड़ देता है लेकिन यह हमारे संकलन समय को 5-6min से ~ 1minute तक लाता है।

यह अब निष्क्रिय है क्योंकि हमने ऐप्पल से इसके बारे में पूछा और उन्होंने सलाह दी कि हमें निम्नलिखित कार्य करना चाहिए:

  1. 'स्विफ्ट कंपाइलर - कोड जेनरेशन' बिल्ड सेटिंग में 'संपूर्ण मॉड्यूल ऑप्टिमाइज़ेशन' चालू करें। 'Fast, Whole Module Optimization' चयन करें

  1. 'स्विफ्ट कंपाइलर - कस्टम फ्लैग' में, आपके विकास के लिए, '-Onone' जोड़ें

जब ये झंडे सेट होते हैं, तो संकलक सभी स्विफ्ट फ़ाइलों को एक चरण में संकलित करेगा। हमने अपनी मर्ज स्क्रिप्ट के साथ पाया यह व्यक्तिगत रूप से फ़ाइलों को संकलित करने से बहुत तेज है। हालांकि, ' -Onone' ओवरराइड के बिना, यह पूरे मॉड्यूल को भी अनुकूलित करेगा, जो धीमा है। जब हम अन्य स्विफ्ट झंडे में '-Onone' ध्वज सेट करते हैं, तो यह अनुकूलन को रोकता है, लेकिन यह एक चरण में सभी स्विफ्ट फ़ाइलों को संकलित करना बंद नहीं करता है।

पूरे मॉड्यूल अनुकूलन के बारे में अधिक जानकारी के लिए, यहां ऐप्पल के ब्लॉग पोस्ट की जांच करें - https://swift.org/blog/whole-module-optimizations/

हमने पाया है कि ये सेटिंग्स हमारे स्विफ्ट कोड को 30 सेकंड में संकलित करने की अनुमति देती हैं :-) मुझे इस बात का कोई सबूत नहीं है कि यह अन्य परियोजनाओं पर कैसे काम करेगा, लेकिन अगर मैं स्विफ्ट संकलन के समय अभी भी आपके लिए एक मुद्दा है तो मैं इसे आज़माकर सुझाव देता हूं।

आपके ऐप स्टोर के लिए नोट बनाता है, आपको '-Onone' ध्वज छोड़ना चाहिए, क्योंकि उत्पादन के निर्माण के लिए अनुकूलन की अनुशंसा की जाती है।