धीमे संकलन वाले वातावरण में कोडिंग के लिए सबसे अच्छा aproach क्या है


15

मैं सी # में टीडीडी शैली में कोडिंग करता था - कोड का एक छोटा हिस्सा / लिखना या बदलना, 10 सेकंड में फिर से संकलित करना संपूर्ण समाधान, परीक्षणों को फिर से चलाना और फिर से संकलित करना। आसान...

उस विकास पद्धति ने कुछ वर्षों तक मेरे लिए बहुत अच्छा काम किया, पिछले साल तक जब मुझे C ++ कोडिंग में वापस जाना पड़ा और यह वास्तव में महसूस हुआ कि मेरी उत्पादकता में नाटकीय रूप से कमी आई है। एक भाषा के रूप में C ++ कोई समस्या नहीं है - मुझे C ++ देव अनुभव के लिए बहुत कुछ था ... लेकिन अतीत में।

मेरी उत्पादकता अभी भी एक छोटी परियोजनाओं के लिए ठीक है, लेकिन यह तब और खराब हो जाती है जब परियोजना के आकार में वृद्धि और एक बार संकलन समय 10+ मिनट हिट हो जाता है। और अगर मुझे त्रुटि मिलती है तो मुझे फिर से संकलन शुरू करना होगा, आदि यह केवल विशुद्ध रूप से निराशाजनक है।

इस प्रकार मैंने निष्कर्ष निकाला कि एक छोटे से विखंडन में (जैसा कि पहले) स्वीकार्य नहीं है - किसी भी सिफारिशें कि मैं खुद को एक या एक घंटे के लिए कोडिंग की पुरानी आदत में कैसे डाल सकता हूं, जब मैन्युअल रूप से कोड की समीक्षा किए बिना (तेजी से सी # संकलक पर भरोसा किए बिना) , और केवल एक-दो घंटे में एक बार पुनः परीक्षण / पुन: चल रहा इकाई परीक्षण।

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


stackoverflow.com/questions/5078409/… ये संभवतः एक स्थान पर मर्ज / किए जाने चाहिए।
बेन एल

C ++ संकलन समय को तेज करने के लिए laso stackoverflow.com/questions/373142/… देखें ।
ग्रहण

2
एक तलवारबाज़ी शुरू करो । ; पी
स्टीवन ज्यूरिस

पिछली बार मैंने C ++ को बयाना में इस्तेमाल किया था, पूर्व संकलित हेडर का उपयोग करके एक कारक चार द्वारा संकलन समय में कटौती की।
gnasher729

जवाबों:


16

मेरे दिमाग में कई बातें आती हैं:

  1. वितरित संकलन का उपयोग करें । आप इसे GCC ("distCC"?) या VC ( Xoreax 'IncrediBuild के साथ बिल्कुल सस्ता नहीं कर सकते, लेकिन इस पर खर्च किए गए हर प्रतिशत के बराबर है।)।

  2. अपनी परियोजना को गतिशील रूप से भरी हुई पुस्तकालयों में विभाजित करें , और सावधानी से उन पर निर्भरता को कम करने का प्रयास करें। छोटे निष्पादनयोग्य बहुत तेजी से लिंक करते हैं।

  3. पूरे बड़े आवेदन के बजाय छोटे परीक्षण परियोजनाओं के खिलाफ कार्यक्रम ।

  4. संकलन-समय पर एल्गोरिदम प्रदर्शन करने के लिए टेम्पलेट-मेटा प्रोग्रामिंग को रोजगार दें । हां, यह वास्तव में संकलन समय में वृद्धि करेगा, लेकिन यह परीक्षण के लिए आवश्यक टर्नआर्ड्स को भी कम करेगा: यदि यह ठीक संकलन करता है, तो यह किया जाता है।

  5. हार्डवेयर में निवेश करें । अधिक सीपीयू कर्नेल (आपकी मशीन में या अन्य में) वितरित संकलन के साथ आश्चर्य करेंगे, और बहुत सारी मेमोरी प्लस (एक तेज डिस्क (एचडीडी के बजाय एसएसडी) बहुत मदद करेगी। यदि आपके पास 64 बिट सिस्टम और अश्लील मात्रा में रैम है, तो रैम डिस्क पर संकलन एक अविश्वसनीय गति को बढ़ावा दे सकता है।


1
संकलक कैश वास्तव में मेरे अनुभव में वितरित संकलन से बेहतर विचार है।
pqnet

रैम डिस्क बनाम एसएसडी की बात करते हुए, मैं काफी हैरान था कि यह संकलन की गति में इतनी वृद्धि नहीं लाया। मेरी वर्तमान परियोजना (एंड्रॉइड पर जावा) SSD से ~ 45 सेकंड में और ~ डिस्क से 40 सेकंड में स्वच्छ स्थिति से संकलित होती है (और पूरे टूलकिन रैम डिस्क में है, न कि केवल स्रोत)। नाटकीय वृद्धि नहीं, मैं कहूंगा।
हस्सेमुलेटर

10

एक अन्य तकनीकी समाधान जो अभी तक दूसरों द्वारा उल्लिखित नहीं है, वह नियमित हार्ड ड्राइव के बजाय सॉलिड स्टेट ड्राइव पर स्विच कर रहा है। पिछली परियोजना में मैंने काम किया था, SSDs ने निर्माण समय को 30 मिनट से 3 तक की सीमा तक लाया।

बेशक, वे महंगे हैं। अपने बॉस के लिए, एक बार के निवेश की कीमत के खिलाफ खोए हुए डेवलपर समय की कीमत की गणना करें। निवेश शायद कुछ महीनों में खुद के लिए भुगतान करता है।


6
यह तो दिलचस्प है। कहते हैं कि बिल्ड समय का 90% I / O डिस्क विलंबता है।
माइक डनलैवी

मैंने 90% की कमी नहीं देखी है, लेकिन एक पर्याप्त है। यह संकलन को गति देने के लिए प्रतीत नहीं होता है, लेकिन यह निश्चित रूप से लिंकिंग को गति देता है। यदि आप किसी बड़ी परियोजना में छोटे बदलाव कर रहे हैं (इसलिए एक बदलाव में बहुत संकलन नहीं है), और राहत देते हुए, आप इसे अच्छी तरह से प्राप्त कर सकते हैं। (यह विजुअल स्टूडियो 2008 है, जिसमें C ++ का उपयोग किया गया है।)
डेविड थॉर्नले

1
यह एक अच्छा विचार है। इसके अलावा, आपके फाइलसिस्टम पर रैम का एक हिस्सा बढ़ाना तेजी से काम करेगा, और यह सस्ता है।
गोरान जोविक

2
रामडिस्क और भी तेज (और सस्ता) है।
तर्क

1
@ जॉन: हाँ, एक अच्छी तरह से लिखा संकलक (IMHO) I / O बाध्य होना चाहिए।
माइक डनलवेई

3

अधिक योजना, बड़े विखंडू में कोड, यूनिट-परीक्षणों के बजाय एकीकरण परीक्षण लिखते हैं और रातोंरात बिल्ड + टेस्ट सूट चलाते हैं।


3

लंबे संकलन समय कभी-कभी एक समस्या होती है, लेकिन पहले से ही उल्लिखित संशोधन से (अधिकतर) उस पर काबू पाने में मदद मिल सकती है।

अधिक गंभीर ऐसे वातावरण में फंस रहा है जहां आप बिल्कुल भी संकलन नहीं कर सकते हैं, जहां परीक्षण / विकास पर्यावरण के लिए आवेदन के लिए एक और महाद्वीप पर प्रत्येक कोड परिवर्तन को दूसरे विभाग में जमा करना होगा, एक प्रक्रिया जिसे पूरा होने में दिन लग सकते हैं।

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

ऐसी स्थितियों में आप जितना संभव हो उतना संभव बनाने की कोशिश करते हैं, ताकि आपके कोड को संकलित करने की कोशिश करने से पहले भी कोई त्रुटि न हो। यह लगभग मुझे लगता है कि मैं मेनफ्रेम प्रोग्रामिंग पर वापस आ गया हूं, जहां हमारे पास सभी संकलन और परीक्षण कार्यों के लिए प्रति माह 5 मिनट का सीपीयू समय उपलब्ध था।


1
लड़का, कि नरक से एक स्थिति है। मुझे मेनफ्रेम के दिन याद हैं। हमने कोड की "डेस्क जाँच" बहुत किया। यह आश्चर्यजनक है कि इस तरह से बहुत कुछ किया गया, जैसे कि चंद्रमा के लिए उड़ानों के अंतहीन सिमुलेशन।
माइक डनलैवी

3

मैं आसानी से याद कर सकता हूं जब बिल्ड में लंबा समय लगता था। कुछ कम करने वाले दृष्टिकोण:

  • पुस्तकालयों या dlls के संयोजन से सिस्टम का निर्माण करें। इस तरह, जब आप कुछ कोड को संशोधित करते हैं, तो केवल वही भाग जिसे पुन: संकलित करने की आवश्यकता होती है, वह आपका भाग है।
  • कोड में जितने अंक आपको एक फीचर को लागू करने के लिए संपादित करने की जरूरत है, न केवल यह कि आपको कितना संपादन करना पड़ता है, बल्कि आवृत्ति, जिसके साथ आप कीड़े डालते हैं, संकलन-डीबग-एडिट-संकलन लूप को बढ़ाता है। कुछ भी जो कोड की अतिरेक को कम करता है, जैसे कि DRY, मदद करता है।
  • यदि आप डीबगर में हैं, और डीबगर को छोड़ने के बिना संपादित, पुन: व्यवस्थित और जारी रख सकते हैं, तो यह वास्तव में सहायक है।

2

एक संकलन के लिए 10+ मिनट? गंभीरता से?

क्या आप एक आईडीई का उपयोग कर रहे हैं जो वृद्धिशील इमारत (जैसे ग्रहण) करता है? यदि नहीं, तो आपको शायद होना चाहिए, यह मिनटों के बजाय सेकंड में मूल संकलन करेगा।

या आप एकीकरण सामग्री के बारे में बात कर रहे हैं, जहां आपको अपने परिवर्तन का परीक्षण करने के लिए पूरे ऐप का निर्माण करने की आवश्यकता है? यदि ऐसा है, तो पूर्ण बिल्ड करने से पहले प्रमुख बग्स आपके कोड से बाहर हैं यह सुनिश्चित करने के लिए छोटे परीक्षणों को देखें।


5
10 मीटर छोटा है। मैंने एक ऐसी परियोजना के लिए काम किया है जिसे एक-कोर मशीन, पीसीएच और सभी पर खरोंच से संकलन और लिंक करने में एक घंटे का समय लगा। बेशक, स्वचालित रिलीज़ को छोड़कर कोई भी इसे केवल एक प्रोसेसर कोर पर नहीं बनाएगा, लेकिन फिर भी ... यदि आपको किसी हेडर में कुछ बदलना है जो कि हर जगह (स्ट्रिंग हेरफेर, त्रुटि हैंडलिंग) के बारे में शामिल है, तो आप पागल हो सकते हैं।
sbi

2
एक सिस्टम पर काम करते थे (वर्षों पहले), एक पूर्ण निर्माण के लिए, संकलन के लिए 48 घंटे। बेशक एक पूर्ण निर्माण केवल शुक्रवार शाम को शुरू किया गया था, उम्मीद है कि जब हम सोमवार को कार्यालय वापस आएंगे तब किया जाएगा। हमने जरूरत के अनुसार छोटे मॉड्यूल बनाए (एक ही DLL कहते हैं)।
jwenting

2
-1 से ऊपर की सभी टिप्पणियाँ यदि मैं TrueDub पर +1 कर सकता हूं। हां, अगर आप सब कुछ recompiling कर रहे हैं तो इसमें बहुत लंबा समय लग सकता है। हालाँकि, अगर किसी भी विचार को निर्भरता प्रबंधन के लिए दिया जाता है, तो 10 घंटे की संपूर्ण पुनरावर्ती परियोजनाओं में एक मिनट से भी कम समय में वृद्धि के मानदंड हो सकते हैं। आप सभी को शर्म आनी चाहिए कि अपने नियोक्ताओं के समय का इंतजार करते हुए अपने recompiles का इंतजार करें जब थोड़ी सी बुद्धिमत्ता लागू करने से बड़ी मात्रा में समय की बचत होगी।
डंक

2
और यदि आप एक छोटी सी दुकान में काम करते हैं जो कई-एमएलओसी प्रोजेक्ट पर बैठने के लिए होता है, तो इसका मतलब है कि कोड का काफी हिस्सा पुराना है, एक दशक पहले कई छोटी परियोजनाओं के रूप में शुरू हुआ, जहां संकलन की गति कभी भी मुद्दा नहीं थी, और निर्भरता प्रबंधन बहुत बुरा है। तो क्या आप ऐसी किसी कंपनी को यह सब बताने के लिए जा रहे हैं और एक और दशक इसे फिर से लिखने में खर्च करेंगे?
भारतीय स्टेट बैंक

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

2

पहला, पहले स्थान पर संकलन करने में इतना समय क्यों लगता है?

  • क्या आपका पर्यावरण (IDE, Make, जो भी हो) वृद्धिशील बिल्ड का समर्थन करता है? यह सुनिश्चित कर लें कि आप केवल बदलावों को ही पूरा करने के बजाय परिवर्तन को फिर से कर रहे हैं।
  • यदि आपके पास मल्टी-कोर मशीन है, तो आपका आईडीई समानांतर संकलन का समर्थन कर सकता है। मुझे पता है कि विजुअल स्टूडियो ऐसा करता है। जाहिर है तो gcc है। तो एक बेहतर मशीन प्राप्त करें, और समानांतर संकलन सक्षम करें।
  • पहले से तैयार हेडर का उपयोग करने पर विचार करें।
  • यदि आप वह सब करने की कोशिश करते हैं, और संकलन अभी भी धीमा है, तो अपने कोड की समीक्षा करें। अनावश्यक निर्भरता के लिए देखो। क्या आप किसी शीर्ष लेख को शामिल कर रहे हैं जहाँ एक आगे की घोषणा पर्याप्त होगी? हेडर पर निर्भरता कम करने के लिए PIMPL मुहावरे का उपयोग करने पर विचार करें।

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

अंत में, यदि आपको अपने परिवर्तनों का परीक्षण करने में अभी भी लंबा समय लगता है, तो उनमें अधिक विचार डालें। अपने संस्करण नियंत्रण प्रणाली में एक बदलाव करना सुनिश्चित करें और परीक्षण से पहले सभी परिवर्तनों की सावधानीपूर्वक समीक्षा करें। संक्षेप में, यह बहुत हद तक एम्बेडेड सिस्टम विकास की तरह है, जहां एक परीक्षण के लिए बदलाव का समय लंबा है, और सिस्टम की स्थिति की जांच करने की आपकी क्षमता सीमित है।

यह मुझे एक और विचार की ओर ले जाता है: लॉगिंग का उपयोग करने के लिए आपका कोड साधन। इस तरह आप देख सकते हैं कि पुनर्निर्माण के बिना समस्या क्या है और एक दर्जन बार फिर से चल रही है।


2
मुझे यकीन नहीं है कि अगर जीसीसी समानांतर संकलनों का समर्थन करता है तो तथ्य यह है कि बनाने या इसी तरह के उपकरण जीसीसी की कई प्रतियां शुरू करेंगे यदि आप इसे भी बताते हैं।
ज़ाचरी के

1
PIMPL के लिए +1। मैंने एक ऐसी परियोजना पर काम किया, जहां निर्माण समय नियंत्रण से बाहर हो गया। उस परियोजना में, मैंने इस बात पर ध्यान नहीं दिया कि प्रत्येक हेडर में कितने अन्य हेडर शामिल थे। अपने अगले प्रोजेक्ट पर, मैंने PIMPL का व्यापक उपयोग करके इसे कम से कम करने के लिए एक बिंदु बनाया। बिल्ड समय बहुत अच्छा होना जारी है, हालांकि दूसरी परियोजना शायद पहले के आकार से दोगुनी है।
जेसन बी

1

आपको शायद एक बहु-आयामी दृष्टिकोण की आवश्यकता है:

1) तेज़ बिल्ड सिस्टम। जितने कोर / रैम / फास्ट डिस्क उतने आप खर्च कर सकते हैं। बड़ी सी ++ परियोजनाओं के लिए आप पाएंगे कि डिस्क अक्सर एक सीमक है, इसलिए सुनिश्चित करें कि आपके पास तेज़ हैं।

2) परियोजना का अधिक संशोधन। सामानों को तोड़ दें ताकि बदलाव आसानी से हर चीज का पूर्ण पुन: संकलन न कर सकें। सच कहूँ तो, अलग dll / इतनी फ़ाइलों में जितना संभव हो उतना बुनियादी सामान धक्का ताकि परियोजना का हिस्सा बाकी हिस्सों से पूरी तरह से तलाक हो सके।

3) इंक्रीमेंटल बिल्ड / डिस्ट्रीब्यूट बिल्ड / कैशिंग को आपके पर्यावरण के लिए उपयुक्त बनाता है। कुछ प्रणालियों पर, डिस्टेक (वितरित इमारत) और ccache (आंशिक रूप से निर्मित सामान का कैशिंग) बहुत संकलन समय बचा सकता है।

4) सुनिश्चित करें कि आपका निर्माण अच्छी तरह से समानांतर किया जा सकता है। विशेष रूप से एक मेकफाइल वातावरण में, ऐसी स्थिति में आना मुश्किल नहीं है, जहां आपने गलती से मेकफाइल्स को सेट किया हो, जैसे कि आप समानांतर इमारत नहीं कर सकते।


0

व्यापक लॉगिंग और आंतरिक सत्यापन लंबे समय तक बदलाव के समय के लिए मददगार रहा है। एक बार आपका निर्माण हो जाने के बाद, एक सिंगल रन संभव मुद्दों के एक बड़े सेट को एक ही बार में प्रकट कर सकता है।

बल्कि जटिल एल्गोरिदम या बहीखाता पद्धति के साथ काम करते समय, 'वास्तविक' के समानांतर एक उच्च सरलीकृत संस्करण को शामिल करने में मदद मिल सकती है। किसी भी रन में, आपके पास उपयोगी संदर्भ डेटा शामिल हैं।


0

क्या कहा @sbi और @Michael Kohne ने।

निर्माण प्रक्रिया पर ही समय और ऊर्जा खर्च करें। एक बार हमारे पास एक आलीशान, परिपक्व उत्पाद था जो एक पूर्ण निर्माण के लिए एक घंटे से अधिक समय लेता था। बहुत समय और ऊर्जा यह तय करने में खर्च किया गया था कि निर्माण निर्भरता क्या होने का दावा करती है, और फिर बाद में, वे वास्तव में जो थे, उसे ठीक करना / कम करना। निर्माण समय गिरा ~ 30 मिनट।

निर्माण उपकरण बदलने से इसे और अधिक गिरा दिया गया। एक बहु-भाग परियोजना के लिए, 'लिंक' किसी भी लिंक को करने से पहले सभी संकलन कर सकते हैं। एकाधिक मेकफाइल्स का उपयोग करके 'मेक' एक प्रोजेक्ट के लिंक से पहले किसी एक प्रोजेक्ट का संकलन करता है, फिर आगे बढ़ता है।

इसने हमें इस बात पर पहुंचाया कि सभी व्यक्तिगत संकलित आदेशों को बड़े पैमाने पर समानांतर किया जा सकता है। धीमी मशीनों पर 'distcc', मल्टीकोर मशीनों पर / scons -j8। पूर्ण मुट्ठी भर मिनट के लिए नीचे लाया।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.