इस पेज पर बताया गया है कि बार-बार Bazel चलाने पर, Bazel के बिल्ड परफ़ॉर्मेंस को कैसे ऑप्टिमाइज़ करें.
Bazel का रनटाइम स्टेट
Bazel के साथ बातचीत करने की प्रोसेस में, आपस में जुड़े हुए कई हिस्से शामिल होते हैं.
bazel
कमांड लाइन इंटरफ़ेस (सीएलआई), लोगों के लिए इस्तेमाल किया जाने वाला फ़्रंट-एंड टूल है. इस टूल पर, उपयोगकर्ता को निर्देश मिलते हैं.सीएलआई टूल, हर अलग-अलग आउटपुट बेस के लिए, Bazel सर्वर शुरू करता है. आम तौर पर, Bazel सर्वर पर काम करने लगता है. हालांकि, यह कुछ समय बाद बंद हो जाता है, ताकि संसाधनों की बर्बादी न हो.
Bazel सर्वर, दिए गए निर्देश (
build
,run
,cquery
वगैरह) के लिए, लोड होने और विश्लेषण करने के चरण पूरे करता है. इसमें, वह मेमोरी में बिल्ड ग्राफ़ के ज़रूरी हिस्से बनाता है. इस तरह के डेटा स्ट्रक्चर, विश्लेषण कैश के हिस्से के तौर पर, Bazel सर्वर में सेव रहते हैं.Bazel सर्वर, कार्रवाई को पूरा कर सकता है या अगर उसे रिमोट एक्ज़ीक्यूशन के लिए सेट अप किया गया हो, तो वह रिमोट एक्ज़ीक्यूशन के लिए बंद कर सकता है. कार्रवाई के नतीजे भी कैश मेमोरी में सेव होते हैं, जैसे कि ऐक्शन कैश या एक्ज़ीक्यूशन कैश, जो लोकल या रिमोट हो सकता है. इसे Bazel सर्वर के बीच शेयर किया जा सकता है.
Bazel के अनुरोध का नतीजा, आउटपुट ट्री में उपलब्ध कराया जाता है.
Bazel को बार-बार चलाते हुए चलाना
एक सामान्य डेवलपर वर्कफ़्लो में, कोड का एक टुकड़ा बार-बार बनाना (या चलाना) आम बात है. अक्सर, बहुत ज़्यादा फ़्रीक्वेंसी पर, (उदाहरण के लिए, कंपाइलेशन से जुड़ी कुछ गड़बड़ी ठीक करना या फ़ेल हो रहे टेस्ट की जांच करना) किया जाता है. इस स्थिति में, यह ज़रूरी है कि bazel
को बार-बार शुरू करने पर, बार-बार होने वाली कार्रवाई (जैसे, कंपाइलर को शुरू करना या टेस्ट करना) की तुलना में, जितना हो सके उतना कम ओवरहेड देना चाहिए.
इसे ध्यान में रखते हुए, हम Bazel के रनटाइम की स्थिति पर एक और नज़र डालते हैं:
विश्लेषण कैश मेमोरी, डेटा का सबसे अहम हिस्सा है. कोल्ड रन के सिर्फ़ लोड होने और विश्लेषण करने के चरणों में काफ़ी समय लगाया जा सकता है (यानी कि Bazel सर्वर शुरू होने के ठीक बाद की रन या विश्लेषण कैश मेमोरी बंद करने पर). किसी एक सफल कोल्ड बिल्ड (जैसे, प्रोडक्शन रिलीज़) के लिए यह लागत आती है, लेकिन एक ही टारगेट को बार-बार बनाने के लिए, यह ज़रूरी है कि इस लागत को कम किया जाए और हर बार शुरू करने पर दोहराया न जाए.
हालांकि, विश्लेषण की कैश मेमोरी में बार-बार बदलाव होता रहता है. सबसे पहले, यह Bazel सर्वर की इन-प्रोसेस स्थिति का हिस्सा है. इसलिए, सर्वर खोने से कैश मेमोरी मिट जाती है. हालांकि, कैश मेमोरी भी बहुत आसानी से अमान्य हो जाती है: उदाहरण के लिए, कई bazel
कमांड लाइन फ़्लैग की वजह से
कैश मेमोरी को खारिज कर दिया जाता है. ऐसा इसलिए होता है, क्योंकि कई फ़्लैग, बिल्ड ग्राफ़ पर असर डालते हैं (उदाहरण के लिए, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट की वजह से). फ़्लैग में किए गए कुछ बदलावों की वजह से भी Bazel सर्वर रीस्टार्ट हो सकता है (जैसे कि स्टार्टअप के विकल्प बदलना).
अच्छी परफ़ॉर्मेंस कैश मेमोरी से भी परफ़ॉर्मेंस बेहतर होती है. एक्ज़ीक्यूशन कैश को स्थानीय तौर पर डिस्क पर या दूर से सेव किया जा सकता है. इस कैश मेमोरी को Bazel सर्वर के साथ और डेवलपर के बीच शेयर किया जा सकता है.
कैश मेमोरी में सेव किए गए विश्लेषण को खारिज करने से बचें
अगर विश्लेषण की कैश मेमोरी मिटा दी गई हो या सर्वर रीस्टार्ट किया गया हो, तो Bazel एक चेतावनी प्रिंट करेगा. बार-बार इस्तेमाल के दौरान इनमें से किसी से बचना चाहिए:
बार-बार किए जाने वाले वर्कफ़्लो के बीच में
bazel
फ़्लैग को बदलते समय ध्यान रखें. उदाहरण के लिए,bazel build -c opt
कोbazel cquery
के साथ मिक्स करने पर, हर कमांड से दूसरे निर्देश की ऐनलिसिस कैश मेमोरी मिट जाती है. आम तौर पर, किसी खास वर्कफ़्लो के लिए फ़्लैग के तय सेट का इस्तेमाल करने की कोशिश करें.Bazel सर्वर बंद होने से, विश्लेषण वाली कैश मेमोरी मिट जाती है. Bazel सर्वर को इस्तेमाल में न होने पर, कॉन्फ़िगर किया जा सकता है. इसके बाद, यह बंद हो जाता है. आप इस समय अपनी ज़रूरत के हिसाब से, bazelrc फ़ाइल से कॉन्फ़िगर कर सकते हैं. स्टार्टअप फ़्लैग बदलने पर भी सर्वर रीस्टार्ट होता है. इसलिए, अगर हो सके, तो फ़्लैग करने से बचें.
ध्यान रखें कि अगर Bazel के चालू रहने के दौरान, Ctrl-C को बार-बार दबाया जाता है, तो Bazel सर्वर बंद हो जाता है. जिस मौजूदा बिल्ड की अब ज़रूरत नहीं है उसमें रुकावट डालकर समय बचाने की कोशिश करना आकर्षक है. हालांकि, मौजूदा अनुरोध को अच्छी तरह खत्म करने का अनुरोध करने के लिए, सिर्फ़ एक बार Ctrl-C दबाएं.
अगर आपको एक ही फ़ाइल फ़ोल्डर से फ़्लैग के कई सेट इस्तेमाल करने हैं, तो
--output_base
फ़्लैग के साथ अलग-अलग, कई आउटपुट बेस का इस्तेमाल करें. हर आउटपुट बेस को अपना Bazel सर्वर मिलता है.
इस स्थिति को चेतावनी के बजाय गड़बड़ी वाला बनाने के लिए, --noallow_analysis_cache_discard
फ़्लैग का इस्तेमाल किया जा सकता है (Bzel 6.4.0 में शुरू किया गया)