पायथन कोडच्या ४ दशलक्ष ओळी तपासण्याचा मार्ग. भाग 4

आज आम्ही ड्रॉपबॉक्सने पायथन कोडच्या अनेक दशलक्ष ओळींसाठी प्रकार नियंत्रण कसे आयोजित केले याबद्दल सामग्रीच्या भाषांतराचा दुसरा भाग प्रकाशित करत आहोत.

→ भाग पहिला वाचा

अधिकृत प्रकार समर्थन (PEP 484)

आम्ही हॅक वीक 2014 दरम्यान ड्रॉपबॉक्स येथे mypy सह आमचे पहिले गंभीर प्रयोग केले. हॅक वीक हा ड्रॉपबॉक्सद्वारे आयोजित केलेला एक आठवड्याचा कार्यक्रम आहे. या काळात कर्मचारी त्यांना हवे ते काम करू शकतात! ड्रॉपबॉक्सचे काही सर्वात प्रसिद्ध तंत्रज्ञान प्रकल्प यासारख्या कार्यक्रमांमध्ये सुरू झाले. या प्रयोगाच्या परिणामी, आम्ही असा निष्कर्ष काढला की मायपी आशादायक दिसत आहे, जरी प्रकल्प अद्याप व्यापक वापरासाठी तयार नाही.

त्या वेळी, पायथन प्रकारच्या संकेत प्रणालींचे मानकीकरण करण्याची कल्पना हवेत होती. मी म्हटल्याप्रमाणे, Python 3.0 पासून फंक्शन्ससाठी टाईप एनोटेशन्स वापरणे शक्य होते, परंतु हे केवळ अनियंत्रित अभिव्यक्ती होते, परिभाषित वाक्यरचना आणि शब्दार्थाशिवाय. कार्यक्रमाच्या अंमलबजावणीदरम्यान, या भाष्यांकडे, बहुतेक, फक्त दुर्लक्ष केले गेले. Hack Week नंतर, आम्ही शब्दार्थांचे प्रमाणीकरण करण्यावर काम करायला सुरुवात केली. हे काम उदयास आले पीईपी 484 (Guido van Rossum, Łukasz Langa आणि मी या दस्तऐवजावर सहयोग केले).

आमचे हेतू दोन बाजूंनी पाहिले जाऊ शकतात. प्रथम, आम्हाला आशा होती की संपूर्ण पायथन इकोसिस्टम टाइप इशारे वापरण्यासाठी एक सामान्य दृष्टीकोन स्वीकारू शकेल (पायथनमध्ये "टाइप एनोटेशन" च्या समतुल्य शब्दाचा वापर केला जातो). हे, संभाव्य जोखीम लक्षात घेता, अनेक परस्पर विसंगत पध्दती वापरण्यापेक्षा चांगले होईल. दुसरे, आम्हाला पायथन समुदायातील अनेक सदस्यांसह टाईप एनोटेशन मेकॅनिझमवर खुलेपणाने चर्चा करायची होती. ही इच्छा अंशतः या वस्तुस्थितीद्वारे निर्देशित केली गेली होती की आम्ही पायथन प्रोग्रामरच्या व्यापक लोकांच्या दृष्टीने भाषेच्या मूलभूत कल्पनांपासून "धर्मत्यागी" सारखे दिसू इच्छित नाही. ही डायनॅमिकली टाइप केलेली भाषा आहे, जी "डक टायपिंग" म्हणून ओळखली जाते. समुदायामध्ये, अगदी सुरुवातीस, स्थिर टायपिंगच्या कल्पनेबद्दल थोडीशी संशयास्पद वृत्ती मदत करू शकली नाही परंतु उद्भवू शकली नाही. परंतु स्थिर टायपिंग अनिवार्य होणार नाही हे स्पष्ट झाल्यानंतर (आणि लोकांना ते प्रत्यक्षात उपयुक्त असल्याचे समजल्यानंतर) ही भावना अखेरीस कमी झाली.

प्रकार संकेत वाक्यरचना जो अखेरीस स्वीकारला गेला तो mypy त्या वेळी समर्थन केलेल्या सारखाच होता. PEP 484 3.5 मध्ये Python 2015 सह रिलीझ झाले. पायथन ही आता डायनॅमिकली टाइप केलेली भाषा नव्हती. मला या घटनेचा पायथन इतिहासातील एक महत्त्वाचा टप्पा म्हणून विचार करायला आवडते.

स्थलांतराची सुरुवात

2015 च्या शेवटी, ड्रॉपबॉक्सने mypy वर काम करण्यासाठी तीन लोकांची टीम तयार केली. त्यात गुइडो व्हॅन रोसम, ग्रेग प्राइस आणि डेव्हिड फिशर यांचा समावेश होता. त्या क्षणापासून, परिस्थिती अत्यंत वेगाने विकसित होऊ लागली. मायपीच्या वाढीतील पहिला अडथळा कामगिरीचा होता. मी वर सूचित केल्याप्रमाणे, प्रकल्पाच्या सुरुवातीच्या दिवसांमध्ये मी मायपी अंमलबजावणीचे C मध्ये भाषांतर करण्याचा विचार केला होता, परंतु ही कल्पना आताच्या यादीतून बाहेर पडली आहे. आम्ही CPython इंटरप्रिटर वापरून सिस्टम चालवण्यामध्ये अडकलो होतो, जे mypy सारख्या साधनांसाठी पुरेसे वेगवान नाही. (PyPy प्रकल्प, JIT कंपायलरसह पर्यायी पायथन अंमलबजावणी, आम्हाला देखील मदत झाली नाही.)

सुदैवाने, येथे काही अल्गोरिदमिक सुधारणा आमच्या मदतीसाठी आल्या आहेत. पहिले शक्तिशाली "प्रवेगक" म्हणजे वाढीव तपासणीची अंमलबजावणी. या सुधारणेमागील कल्पना सोपी होती: जर मायपीच्या मागील रनपासून सर्व मॉड्यूलची अवलंबित्व बदलली नसेल, तर आपण अवलंबनांसह कार्य करताना मागील रन दरम्यान कॅशे केलेला डेटा वापरू शकतो. आम्हाला फक्त सुधारित फायली आणि त्यांच्यावर अवलंबून असलेल्या फाइल्सवर प्रकार तपासणी करणे आवश्यक आहे. Mypy आणखी थोडे पुढे गेले: जर मॉड्यूलचा बाह्य इंटरफेस बदलला नाही, तर मायपीने असे गृहीत धरले की हे मॉड्यूल आयात केलेले इतर मॉड्यूल पुन्हा तपासण्याची आवश्यकता नाही.

मोठ्या प्रमाणात विद्यमान कोडचे भाष्य करताना वाढीव तपासणीने आम्हाला खूप मदत केली आहे. मुद्दा असा आहे की या प्रक्रियेत सहसा mypy च्या अनेक पुनरावृत्ती रन समाविष्ट असतात कारण भाष्ये हळूहळू कोडमध्ये जोडली जातात आणि हळूहळू सुधारली जातात. mypy ची पहिली रन अजूनही खूप मंद होती कारण त्यात तपासण्यासाठी खूप अवलंबित्व होते. त्यानंतर, परिस्थिती सुधारण्यासाठी, आम्ही रिमोट कॅशिंग यंत्रणा लागू केली. स्थानिक कॅशे कालबाह्य होण्याची शक्यता mypy ला आढळल्यास, तो केंद्रीकृत रेपॉजिटरीमधून संपूर्ण कोडबेससाठी वर्तमान कॅशे स्नॅपशॉट डाउनलोड करतो. त्यानंतर हा स्नॅपशॉट वापरून वाढीव तपासणी करते. याने मायपीची कामगिरी वाढवण्याच्या दिशेने आणखी एक मोठे पाऊल उचलले आहे.

ड्रॉपबॉक्समध्ये प्रकार तपासणीचा हा जलद आणि नैसर्गिक अवलंब करण्याचा काळ होता. 2016 च्या अखेरीस, आमच्याकडे टाइप भाष्यांसह पायथन कोडच्या अंदाजे 420000 ओळी आधीच होत्या. अनेक वापरकर्ते प्रकार तपासणीबद्दल उत्साही होते. अधिकाधिक विकास संघ ड्रॉपबॉक्स मायपी वापरत होते.

तेव्हा सर्व काही चांगले दिसत होते, परंतु आम्हाला अजूनही बरेच काही करायचे होते. प्रकल्पातील समस्या क्षेत्रे ओळखण्यासाठी आणि प्रथम कोणत्या समस्यांचे निराकरण करणे आवश्यक आहे हे समजून घेण्यासाठी आम्ही नियतकालिक अंतर्गत वापरकर्ता सर्वेक्षणे करण्यास सुरुवात केली (ही पद्धत आजही कंपनीमध्ये वापरली जाते). सर्वात महत्वाचे, जसे ते स्पष्ट झाले, दोन कार्ये होती. प्रथम, आम्हाला कोडच्या अधिक प्रकारच्या कव्हरेजची आवश्यकता आहे, दुसरे, आम्हाला जलद कार्य करण्यासाठी mypy आवश्यक आहे. हे पूर्णपणे स्पष्ट होते की मायपीला गती देण्याचे आणि कंपनीच्या प्रकल्पांमध्ये ते लागू करण्याचे आमचे काम अद्याप पूर्ण झाले नाही. आम्ही, या दोन कार्यांचे महत्त्व पूर्णतः जाणतो, ते सोडविण्यास तयार आहोत.

अधिक उत्पादकता!

वाढीव तपासण्यांनी mypy जलद केले, परंतु साधन अद्याप पुरेसे जलद नव्हते. अनेक वाढीव तपासण्या सुमारे एक मिनिट चालल्या. याचे कारण चक्रीय आयात होते. पायथनमध्ये लिहिलेल्या मोठ्या कोडबेससह काम केलेल्या कोणालाही हे कदाचित आश्चर्यचकित करणार नाही. आमच्याकडे शेकडो मॉड्यूल्सचे संच होते, त्यापैकी प्रत्येकाने इतर सर्व अप्रत्यक्षपणे आयात केले. आयात लूपमधील कोणतीही फाईल बदलल्यास, mypy ला त्या लूपमधील सर्व फायलींवर प्रक्रिया करावी लागते आणि बहुतेकदा त्या लूपमधून मॉड्यूल आयात करणारे कोणतेही मॉड्यूल. असेच एक चक्र म्हणजे कुप्रसिद्ध "अवलंबन गोंधळ" ज्यामुळे ड्रॉपबॉक्समध्ये खूप त्रास झाला. एकदा या संरचनेत अनेक शेकडो मॉड्युल्स समाविष्ट होते, ते आयात केले जात असताना, प्रत्यक्ष किंवा अप्रत्यक्षपणे, अनेक चाचण्या, ते उत्पादन कोडमध्ये देखील वापरले गेले.

आम्ही वर्तुळाकार अवलंबित्व "अनटँगलिंग" करण्याच्या शक्यतेचा विचार केला, परंतु आमच्याकडे ते करण्यासाठी संसाधने नाहीत. आम्हाला परिचित नव्हते असे बरेच कोड होते. परिणामी, आम्ही एक पर्यायी दृष्टीकोन घेऊन आलो. आम्ही "डिपेंडन्सी टँगल्स" च्या उपस्थितीत देखील mypy त्वरीत कार्य करण्याचे ठरविले. आम्ही मायपी डिमन वापरून हे लक्ष्य साध्य केले. डिमन एक सर्व्हर प्रक्रिया आहे जी दोन मनोरंजक वैशिष्ट्ये लागू करते. प्रथम, ते संपूर्ण कोडबेसची माहिती मेमरीमध्ये संग्रहित करते. याचा अर्थ असा की प्रत्येक वेळी तुम्ही mypy चालवता, तुम्हाला हजारो आयात अवलंबनांशी संबंधित कॅशे डेटा लोड करण्याची गरज नाही. दुसरे म्हणजे, तो काळजीपूर्वक, लहान स्ट्रक्चरल युनिट्सच्या पातळीवर, फंक्शन्स आणि इतर घटकांमधील अवलंबित्वांचे विश्लेषण करतो. उदाहरणार्थ, फंक्शन असल्यास foo फंक्शन कॉल करते bar, नंतर एक अवलंबित्व आहे foo पासून bar. जेव्हा एखादी फाइल बदलते, तेव्हा डिमन प्रथम, अलगावमध्ये, फक्त बदललेल्या फाइलवर प्रक्रिया करतो. ते नंतर त्या फाईलमधील बाह्य दृश्यमान बदल पाहते, जसे की बदललेल्या फंक्शन स्वाक्षरी. डिमन केवळ सुधारित फंक्शन वापरणाऱ्या फंक्शन्सची दुहेरी तपासणी करण्यासाठी आयातीबद्दल तपशीलवार माहिती वापरतो. सामान्यतः, या दृष्टिकोनासह, तुम्हाला फारच कमी कार्ये तपासावी लागतील.

या सर्वांची अंमलबजावणी करणे सोपे नव्हते, कारण मूळ mypy अंमलबजावणी एकावेळी एका फाइलवर प्रक्रिया करण्यावर जास्त लक्ष केंद्रित करते. आम्हाला बऱ्याच सीमारेषेवरील परिस्थितींना सामोरे जावे लागले, ज्याच्या घटनेसाठी कोडमध्ये काहीतरी बदललेल्या प्रकरणांमध्ये वारंवार तपासणी करणे आवश्यक होते. उदाहरणार्थ, जेव्हा वर्गाला नवीन आधार वर्ग नियुक्त केला जातो तेव्हा असे होते. एकदा आम्हाला हवे ते केले की, आम्ही बऱ्याच वाढीव तपासण्याची अंमलबजावणी वेळ काही सेकंदांपर्यंत कमी करू शकलो. हा आम्हाला मोठा विजय वाटत होता.

आणखी उत्पादकता!

मी वर चर्चा केलेल्या रिमोट कॅशिंगसह, मायपी डिमनने प्रोग्रामर वारंवार टाईप चेकिंग चालवताना उद्भवणाऱ्या समस्या जवळजवळ पूर्णपणे सोडवल्या, फायलींच्या छोट्या संख्येत बदल केले. तथापि, कमीतकमी अनुकूल वापर प्रकरणात सिस्टम कार्यप्रदर्शन अद्याप इष्टतम नाही. mypy च्या स्वच्छ स्टार्टअपला 15 मिनिटांपेक्षा जास्त वेळ लागू शकतो. आणि आम्हाला आनंद झाला असता त्यापेक्षा हे खूप जास्त होते. प्रोग्रामर नवीन कोड लिहिणे आणि विद्यमान कोडमध्ये भाष्ये जोडणे सुरू ठेवल्याने प्रत्येक आठवड्यात परिस्थिती आणखी वाईट होत गेली. आमचे वापरकर्ते अजूनही अधिक कार्यक्षमतेसाठी भुकेले होते, परंतु आम्हाला अर्ध्या रस्त्यात भेटून आनंद झाला.

आम्ही मायपीशी संबंधित पूर्वीच्या कल्पनांपैकी एकाकडे परत जाण्याचा निर्णय घेतला. म्हणजे, पायथन कोड सी कोडमध्ये रूपांतरित करण्यासाठी. सायथॉन (एक प्रणाली जी तुम्हाला पायथनमध्ये लिहिलेल्या कोडचे C कोडमध्ये भाषांतर करण्याची परवानगी देते) सह प्रयोग केल्याने आम्हाला कोणतीही दृश्यमान गती मिळाली नाही, म्हणून आम्ही आमचे स्वतःचे कंपाइलर लिहिण्याची कल्पना पुन्हा सुरू करण्याचा निर्णय घेतला. mypy codebase (Python मध्ये लिहिलेले) मध्ये आधीपासूनच सर्व आवश्यक प्रकारच्या भाष्ये असल्याने, आम्हाला वाटले की सिस्टमला गती देण्यासाठी या भाष्यांचा वापर करण्याचा प्रयत्न करणे फायदेशीर ठरेल. या कल्पनेची चाचणी घेण्यासाठी मी पटकन एक प्रोटोटाइप तयार केला. विविध मायक्रो-बेंचमार्क्सवरील कार्यक्षमतेत 10 पटीने वाढ झाली आहे. सायथॉन वापरून पायथन मॉड्यूल्स सी मॉड्यूल्समध्ये संकलित करणे आणि रन-टाइम टाइप चेकमध्ये टाइप एनोटेशन्स बदलणे (सामान्यत: टाइप एनोटेशन्स रन-टाइममध्ये दुर्लक्षित केली जातात आणि फक्त टाइप चेकिंग सिस्टमद्वारे वापरली जातात) ही आमची कल्पना होती. आम्ही प्रत्यक्षात पायथन मधील mypy अंमलबजावणीचे एका भाषेत भाषांतर करण्याची योजना आखली आहे जी स्टॅटिकली टाइप करण्यासाठी डिझाइन केलेली होती, जी पायथनसारखीच दिसेल (आणि बहुतेक भागांसाठी कार्य करते). (या प्रकारचे क्रॉस-लँग्वेज स्थलांतर हे मायपी प्रकल्पाची परंपरा बनले आहे. मूळ मायपी अंमलबजावणी अलोरेमध्ये लिहिली गेली होती, त्यानंतर जावा आणि पायथनचा सिंटॅक्टिक संकर होता).

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

कंपाइलर, ज्याला आम्ही mypyc म्हणतो (कारण ते प्रकारांचे विश्लेषण करण्यासाठी मायपीचा फ्रंट-एंड म्हणून वापर करते), तो एक अतिशय यशस्वी प्रकल्प ठरला. एकंदरीत, आम्ही कॅशिंगशिवाय वारंवार mypy रनसाठी अंदाजे 4x स्पीडअप प्राप्त केले. mypyc प्रकल्पाचा गाभा विकसित करण्यासाठी मायकेल सुलिव्हन, इव्हान लेव्हकिव्हस्की, ह्यू हॅन आणि स्वतःची एक छोटी टीम सुमारे 4 कॅलेंडर महिने लागली. mypy पुन्हा लिहिण्यासाठी आवश्यक असलेल्या कामापेक्षा ही रक्कम खूपच कमी होती, उदाहरणार्थ, C++ किंवा Go मध्ये. आणि दुसऱ्या भाषेत पुनर्लेखन करताना आम्हाला प्रकल्पात जेवढे बदल करावे लागतील त्यापेक्षा खूप कमी बदल करावे लागले. आम्हाला आशा आहे की आम्ही mypyc अशा स्तरावर आणू शकतो की इतर ड्रॉपबॉक्स प्रोग्रामर त्यांचा कोड संकलित करण्यासाठी आणि वेग वाढवण्यासाठी त्याचा वापर करू शकतील.

कामगिरीची ही पातळी गाठण्यासाठी, आम्हाला काही मनोरंजक अभियांत्रिकी उपाय लागू करावे लागले. अशा प्रकारे, कंपाइलर जलद, निम्न-स्तरीय C रचना वापरून अनेक ऑपरेशन्स वाढवू शकतो, उदाहरणार्थ, संकलित फंक्शन कॉल C फंक्शन कॉलमध्ये अनुवादित केला जातो. आणि असा कॉल इंटरप्रिटेड फंक्शन कॉल करण्यापेक्षा खूप वेगवान आहे. काही ऑपरेशन्स, जसे की डिक्शनरी लुकअप, अजूनही CPython वरून नियमित C-API कॉल वापरून गुंतलेले आहेत, जे संकलित केल्यावर किरकोळ वेगवान होते. आम्ही स्पष्टीकरणाद्वारे तयार केलेल्या सिस्टमवरील अतिरिक्त भार दूर करण्यात सक्षम होतो, परंतु या प्रकरणात कार्यक्षमतेच्या बाबतीत केवळ एक छोटासा फायदा झाला.

सर्वात सामान्य "स्लो" ऑपरेशन्स ओळखण्यासाठी, आम्ही कोड प्रोफाइलिंग केले. या डेटासह सशस्त्र, आम्ही एकतर mypyc मध्ये बदल करण्याचा प्रयत्न केला जेणेकरून ते अशा ऑपरेशन्ससाठी जलद C कोड तयार करेल किंवा जलद ऑपरेशन्स वापरून संबंधित Python कोड पुन्हा लिहू शकेल (आणि काहीवेळा आमच्याकडे त्या किंवा इतर समस्येसाठी पुरेसे सोपे उपाय नव्हते) . कंपाइलर आपोआप समान परिवर्तन करण्यापेक्षा पायथन कोड पुन्हा लिहिणे हा समस्येचा एक सोपा उपाय होता. दीर्घकालीन, आम्हाला यापैकी अनेक परिवर्तने स्वयंचलित करायची होती, परंतु त्या वेळी आम्ही कमीत कमी प्रयत्नात मायपीला गती देण्यावर लक्ष केंद्रित केले होते. आणि या ध्येयाकडे वाटचाल करताना, आम्ही अनेक कोपरे कापले.

पुढे चालू…

प्रिय वाचक! जेव्हा तुम्ही मायपी प्रकल्पाच्या अस्तित्वाबद्दल शिकलात तेव्हा तुमची छाप काय होती?

स्त्रोत: www.habr.com