अजगर कोड की 4 मिलियन लाइनों की जाँच करने का तरीका। भाग २

आज हम इस बारे में सामग्री के अनुवाद के दूसरे भाग को प्रकाशित करते हैं कि कैसे ड्रॉपबॉक्स ने पायथन कोड की कई मिलियन लाइनों का प्रकार नियंत्रित किया।



→ पहला भाग पढ़ें

औपचारिक प्रकार का समर्थन (पीईपी 484)

हमने हैक वीक 2014 के दौरान ड्रॉपबॉक्स पर mypy के साथ पहला गंभीर प्रयोग किया। हैक वीक एक सप्ताह के लिए ड्रॉपबॉक्स द्वारा आयोजित एक घटना है। इस समय, कर्मचारी कुछ भी काम कर सकते हैं! ड्रॉपबॉक्स की कुछ सबसे प्रसिद्ध प्रौद्योगिकी परियोजनाएं इसी तरह की घटनाओं पर शुरू हुईं। इस प्रयोग के परिणामस्वरूप, हम इस निष्कर्ष पर पहुँचे कि मैपीी आशाजनक दिखती है, हालाँकि यह परियोजना अभी तक व्यापक उपयोग के लिए तैयार नहीं थी।

उस समय, पायथन प्रकारों के लिए हाइटिंग सिस्टम को मानकीकृत करने का विचार हवा में था। जैसा कि मैंने कहा, पायथन 3.0 के साथ शुरू, आप कार्यों के लिए प्रकार एनोटेशन का उपयोग कर सकते हैं, लेकिन ये केवल मनमाना अभिव्यक्ति थे, बिना किसी विशिष्ट वाक्यविन्यास और शब्दार्थ के। कार्यक्रम के निष्पादन के दौरान, अधिकांश भाग के लिए, इन एनोटेशन को बस अनदेखा कर दिया गया था। हैक वीक के बाद, हमने शब्दार्थ मानकीकरण पर काम करना शुरू कर दिया। इस काम के कारण PEP 484 (Guido van Rossum, Lukas Langa और I ने इस दस्तावेज़ में सहयोग किया) का उदय हुआ।

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

टाइप संकेत के लिए परिणामी वाक्यविन्यास उस समय समर्थित एक मैपी के समान था। PEP 484 2015 में पायथन 3.5 के साथ बाहर आया। पायथन अब एक भाषा नहीं थी जो केवल गतिशील टाइपिंग का समर्थन करती थी। मैं इस घटना को पायथन के इतिहास में एक महत्वपूर्ण मील का पत्थर मानना ​​पसंद करता हूं।

प्रवास की शुरुआत

2015 के अंत में, तीन लोगों की टीम को ड्रॉपबॉक्स में मैपी पर काम करने के लिए बनाया गया था। इसमें गुइडो वैन रोसुम, ग्रेग प्राइस और डेविड फिशर शामिल थे। उस क्षण से स्थिति बहुत तेज़ी से विकसित होने लगी। Mypy विकास के लिए पहली बाधा प्रदर्शन था। जैसा कि मैंने पहले ही ऊपर संकेत दिया है, परियोजना के विकास की शुरुआती अवधि में, मैंने मैपी के कार्यान्वयन को सी में अनुवाद करने के बारे में सोचा था, लेकिन इस विचार को अब तक की सूचियों से हटा दिया गया है। हम इस तथ्य के साथ फंस गए हैं कि हमने सिस्टम को शुरू करने के लिए सीपीथॉन दुभाषिया का उपयोग किया, जो कि खस्ता जैसे उपकरणों के लिए पर्याप्त तेज नहीं है। (PyPy प्रोजेक्ट, एक जेआईटी संकलक के साथ पायथन का वैकल्पिक कार्यान्वयन, या तो हमारी मदद नहीं करता था।)

सौभाग्य से, यहाँ कुछ एल्गोरिथम सुधार हमारी सहायता के लिए आए। पहले शक्तिशाली "त्वरक" वृद्धिशील सत्यापन का कार्यान्वयन था। इस सुधार का विचार सरल था: यदि माई के पिछले लॉन्च के बाद से मॉड्यूल की सभी निर्भरताएं नहीं बदली हैं, तो हम निर्भरता के साथ काम करते हुए पिछले सत्र के दौरान कैश किए गए डेटा का उपयोग कर सकते हैं। हमें बस इतना करना था कि संशोधित फाइलों में और उन फाइलों पर जाँच की जाए जो उन पर निर्भर थी। Mypy थोड़ा और आगे बढ़ गया: यदि मॉड्यूल का बाहरी इंटरफ़ेस नहीं बदला - mypy ने सोचा कि इस मॉड्यूल को आयात करने वाले अन्य मॉड्यूल को फिर से जांचना नहीं चाहिए।

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

यह ड्रॉपबॉक्स प्रकार की जाँच प्रणाली के त्वरित और प्राकृतिक परिचय की अवधि थी। 2016 के अंत तक, हमारे पास पहले से ही टाइप एनोटेशन वाले पायथन कोड की 420,000 पंक्तियाँ थीं। कई उपयोगकर्ता प्रकार की जाँच के बारे में उत्साहित थे। ड्रॉपबॉक्स mypy का उपयोग अधिक से अधिक विकास टीमों द्वारा किया गया है।

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

अधिक प्रदर्शन!

वृद्धिशील जाँच ने खांसी को तेज किया, लेकिन यह उपकरण अभी भी पर्याप्त तेज नहीं था। कई वृद्धिशील जाँच लगभग एक मिनट तक चली। इसका कारण चक्रीय आयात था। यह शायद किसी को भी आश्चर्यचकित नहीं करेगा जिसने पायथन में लिखे बड़े कोडबेस के साथ काम किया है। हमारे पास सैकड़ों मॉड्यूल थे, जिनमें से प्रत्येक ने अप्रत्यक्ष रूप से सभी दूसरों को आयात किया। यदि आयात चक्र की कोई भी फ़ाइल संशोधित हुई, तो इस चक्र में शामिल सभी फ़ाइलों को संसाधित करने के लिए mypy को संसाधित करना पड़ा, और अक्सर इस चक्र से मॉड्यूल आयात करने वाले किसी भी मॉड्यूल को भी। ऐसा ही एक चक्र था कुख्यात "निर्भरता की उलझन", जिसके कारण ड्रॉपबॉक्स में बहुत परेशानी हुई। एक बार इस संरचना में कई सौ मॉड्यूल शामिल थे, जबकि इसे आयात किया गया था, प्रत्यक्ष या अप्रत्यक्ष रूप से, बहुत सारे परीक्षण, इसका उपयोग उत्पादन कोड में भी किया गया था।

हमने चक्रीय निर्भरताओं को "अनअवरेलिंग" करने की संभावना पर विचार किया, लेकिन हमारे पास ऐसा करने के लिए संसाधन नहीं थे। बहुत अधिक कोड था जिससे हम परिचित नहीं थे। परिणामस्वरूप, हमने एक वैकल्पिक तरीका अपनाया। हमने "बहुत निर्भरता गेंदों" होने पर भी तेजी से काम करने का फैसला किया। हमने इसे खौफनाक डेमॉन के साथ पूरा किया। एक डेमन एक सर्वर प्रक्रिया है जो दो दिलचस्प विशेषताओं को लागू करती है। सबसे पहले, यह पूरे कोड आधार के बारे में स्मृति जानकारी रखता है। इसका मतलब है कि हर बार जब आप मैपी चलाते हैं, तो आपको हजारों आयातित निर्भरताओं से संबंधित कैश्ड डेटा डाउनलोड नहीं करना होगा। दूसरे, वह ध्यान से, छोटी संरचनात्मक इकाइयों के स्तर पर, कार्यों और अन्य संस्थाओं के बीच संबंधों का विश्लेषण करता है। उदाहरण के लिए, यदि फ़ंक्शन foo फंक्शन bar कॉल करता है, तो bar पर foo निर्भरता होती है। जब कोई फ़ाइल बदली जाती है, तो डेमॉन पहले, अलगाव में, केवल परिवर्तित फ़ाइल को संसाधित करता है। फिर वह इस फ़ाइल के परिवर्तनों को देखता है जो बाहर से दिखाई देते हैं, जैसे कि परिवर्तित फ़ंक्शन हस्ताक्षर। डेमन केवल उन फ़ंक्शन को डबल-चेक करने के लिए विस्तृत आयात जानकारी का उपयोग करता है जो वास्तव में बदले हुए फ़ंक्शन का उपयोग करते हैं। आमतौर पर, इस दृष्टिकोण के साथ, बहुत कम कार्यों को जांचना पड़ता है।

यह सब लागू करना आसान नहीं था, क्योंकि एक समय में एक फ़ाइल को संसाधित करने के लिए माइपी का मूल कार्यान्वयन भारी रूप से केंद्रित था। हमें कई बॉर्डरलाइन स्थितियों से जूझना पड़ा, जिनके होने पर उन मामलों में बार-बार जांच की आवश्यकता होती है जब कोड में कुछ बदल जाता है। उदाहरण के लिए, ऐसा तब होता है जब एक नया आधार वर्ग एक कक्षा को सौंपा जाता है। हम जो चाहते थे, उसके बाद हम सबसे वृद्धिशील जांच के निष्पादन समय को कुछ सेकंड तक कम करने में सक्षम थे। यह हमें बड़ी जीत लग रही थी।

अधिक प्रदर्शन!

दूरस्थ कैशिंग, जिसे मैंने ऊपर वर्णित किया है, के साथ मिलकर, मैपी डेमॉन ने उन समस्याओं को लगभग पूरी तरह से हल कर दिया है जब प्रोग्रामर अक्सर टाइप चेकिंग चलाता है, जिससे बहुत कम फ़ाइलों में परिवर्तन होता है। हालांकि, इसके उपयोग के कम से कम अनुकूल प्रकार में सिस्टम प्रदर्शन अभी भी इष्टतम से दूर था। Mypy की एक साफ शुरुआत में 15 मिनट से ज्यादा लग सकते थे। और यह हम चाहते हैं की तुलना में बहुत अधिक था। प्रत्येक सप्ताह, स्थिति खराब हो गई, क्योंकि प्रोग्रामर नए कोड लिखना और मौजूदा कोड में एनोटेशन जोड़ना जारी रखते थे। हमारे उपयोगकर्ता अभी भी अधिक प्रदर्शन के लिए तरस रहे थे, लेकिन हम उनसे मिलने के लिए तैयार होने में प्रसन्न थे।

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

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

संकलक, जिसे हमने mypyc नाम दिया है (जैसा कि यह mypy का उपयोग प्रकार विश्लेषण के लिए एक दृश्य के रूप में करता है), एक बहुत ही सफल परियोजना बन गई। सब के सब, हम कैशिंग के बिना mypy के लगातार रन के लगभग 4x तेज त्वरण हासिल किया। मायपाइक परियोजना के मूल का विकास एक छोटी टीम से लगभग 4 कैलेंडर महीने में हुआ जिसमें माइकल सुलिवन, इवान लेवकिव्स्की, ह्यूग हान और मैं शामिल थे। काम की यह राशि म्याऊ को फिर से लिखने के लिए क्या जरूरत होगी, उदाहरण के लिए, C ++ या गो में से बहुत कम महत्वाकांक्षी था। और हमें इस परियोजना में बहुत कम बदलाव करने होंगे, जब हमें इसे दूसरी भाषा में लिखना होगा। हमें यह भी उम्मीद थी कि हम mypyc को इस स्तर पर ला सकते हैं कि अन्य ड्रॉपबॉक्स प्रोग्रामर इसका उपयोग अपने कोड को संकलित करने और गति बढ़ाने के लिए कर सकते हैं।

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

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

जारी रखने के लिए ...

प्रिय पाठकों! जब आप इसके अस्तित्व के बारे में जान गए, तो मेरी परियोजना के आपके क्या प्रभाव थे?