இன்று நாம் டிராப்பாக்ஸ் பல மில்லியன் பைதான் குறியீட்டின் வகைக் கட்டுப்பாட்டை எவ்வாறு ஒழுங்கமைத்தது என்பது பற்றிய பொருளின் மொழிபெயர்ப்பின் இரண்டாம் பகுதியை வெளியிடுகிறோம்.
→
அதிகாரப்பூர்வ வகை ஆதரவு (PEP 484)
ஹேக் வீக் 2014 இன் போது டிராப்பாக்ஸில் மைபியுடன் எங்களின் முதல் தீவிர சோதனைகளை மேற்கொண்டோம். ஹேக் வீக் என்பது டிராப்பாக்ஸால் நடத்தப்படும் ஒரு வார நிகழ்வாகும். இந்த நேரத்தில், ஊழியர்கள் என்ன வேண்டுமானாலும் வேலை செய்யலாம்! டிராப்பாக்ஸின் மிகவும் பிரபலமான தொழில்நுட்பத் திட்டங்கள் சில இது போன்ற நிகழ்வுகளில் தொடங்கியது. இந்தச் சோதனையின் விளைவாக, பரவலான பயன்பாட்டிற்குத் திட்டம் இன்னும் தயாராகவில்லை என்றாலும், mypy நம்பிக்கைக்குரியதாகத் தெரிகிறது என்று நாங்கள் முடிவு செய்தோம்.
அந்த நேரத்தில், பைதான் வகை குறிப்பு அமைப்புகளை தரநிலையாக்கும் யோசனை காற்றில் இருந்தது. நான் சொன்னது போல், பைதான் 3.0 முதல் செயல்பாடுகளுக்கு வகை சிறுகுறிப்புகளைப் பயன்படுத்த முடியும், ஆனால் இவை வரையறுக்கப்பட்ட தொடரியல் மற்றும் சொற்பொருள் இல்லாமல் தன்னிச்சையான வெளிப்பாடுகள். நிரல் செயலாக்கத்தின் போது, இந்த சிறுகுறிப்புகள் பெரும்பாலும் புறக்கணிக்கப்பட்டன. ஹேக் வீக்கிற்குப் பிறகு, சொற்பொருளை தரப்படுத்துவதில் நாங்கள் பணியாற்ற ஆரம்பித்தோம். இந்த வேலை தோற்றத்திற்கு வழிவகுத்தது (Guido van Rossum, Łukasz Langa மற்றும் நான் இந்த ஆவணத்தில் ஒத்துழைத்தோம்).
எங்கள் நோக்கங்களை இரண்டு பக்கங்களில் இருந்து பார்க்க முடியும். முதலில், முழு பைதான் சுற்றுச்சூழலும் வகை குறிப்புகளைப் பயன்படுத்துவதற்கான பொதுவான அணுகுமுறையைக் கடைப்பிடிக்க முடியும் என்று நாங்கள் நம்பினோம் ("வகை சிறுகுறிப்புகளுக்கு" சமமான பைத்தானில் பயன்படுத்தப்படும் சொல்). இது, சாத்தியமான அபாயங்களைக் கருத்தில் கொண்டு, பல பரஸ்பர இணக்கமற்ற அணுகுமுறைகளைப் பயன்படுத்துவதை விட சிறந்ததாக இருக்கும். இரண்டாவதாக, பைதான் சமூகத்தின் பல உறுப்பினர்களுடன் வகை சிறுகுறிப்பு வழிமுறைகளை வெளிப்படையாக விவாதிக்க விரும்பினோம். பரந்த அளவிலான பைதான் புரோகிராமர்களின் பார்வையில் மொழியின் அடிப்படைக் கருத்துக்களிலிருந்து "விசுவாச துரோகிகள்" போல் தோன்ற விரும்ப மாட்டோம் என்ற உண்மையால் இந்த ஆசை ஓரளவு கட்டளையிடப்பட்டது. இது "டக் டைப்பிங்" எனப்படும், மாறும் வகையில் தட்டச்சு செய்யப்பட்ட மொழியாகும். சமூகத்தில், ஆரம்பத்தில், நிலையான தட்டச்சு யோசனைக்கு சற்று சந்தேகத்திற்கிடமான அணுகுமுறை உதவாமல் இருக்க முடியவில்லை. ஆனால் நிலையான தட்டச்சு கட்டாயமாக இருக்கப் போவதில்லை என்பது தெளிவாகத் தெரிந்த பிறகு (மற்றும் அது உண்மையில் பயனுள்ளது என்பதை மக்கள் உணர்ந்த பிறகு) அந்த உணர்வு இறுதியில் குறைந்தது.
இறுதியில் ஏற்றுக்கொள்ளப்பட்ட வகை குறிப்பு தொடரியல் அந்த நேரத்தில் mypy ஆதரித்ததைப் போலவே இருந்தது. PEP 484 பைதான் 3.5 உடன் 2015 இல் வெளியிடப்பட்டது. பைதான் இனி மாறும் வகையில் தட்டச்சு செய்யப்பட்ட மொழியாக இல்லை. இந்த நிகழ்வை பைதான் வரலாற்றில் ஒரு குறிப்பிடத்தக்க மைல்கல்லாக நான் நினைக்க விரும்புகிறேன்.
இடம்பெயர்வு ஆரம்பம்
2015 ஆம் ஆண்டின் இறுதியில், டிராப்பாக்ஸ் மைபியில் பணிபுரிய மூன்று பேர் கொண்ட குழுவை உருவாக்கியது. அவர்களில் கைடோ வான் ரோசம், கிரெக் பிரைஸ் மற்றும் டேவிட் ஃபிஷர் ஆகியோர் அடங்குவர். அந்த தருணத்திலிருந்து, நிலைமை மிக விரைவாக உருவாகத் தொடங்கியது. மைபியின் வளர்ச்சிக்கு முதல் தடையாக இருந்தது செயல்திறன். நான் மேலே குறிப்பிட்டது போல், திட்டத்தின் ஆரம்ப நாட்களில் நான் mypy செயல்படுத்தலை C க்கு மொழிபெயர்ப்பது பற்றி யோசித்தேன், ஆனால் இந்த யோசனை இப்போது பட்டியலில் இருந்து மீறப்பட்டது. CPython மொழிபெயர்ப்பாளரைப் பயன்படுத்தி கணினியை இயக்குவதில் நாங்கள் சிக்கிக்கொண்டோம், இது mypy போன்ற கருவிகளுக்கு போதுமான வேகம் இல்லை. (PyPy திட்டம், JIT கம்பைலருடன் ஒரு மாற்று பைதான் செயல்படுத்தல், எங்களுக்கும் உதவவில்லை.)
அதிர்ஷ்டவசமாக, சில அல்காரிதம் மேம்பாடுகள் இங்கே எங்கள் உதவிக்கு வந்துள்ளன. முதல் சக்திவாய்ந்த "முடுக்கி" என்பது அதிகரிக்கும் சோதனையை செயல்படுத்துவதாகும். இந்த மேம்பாட்டிற்குப் பின்னால் உள்ள யோசனை எளிமையானது: mypy இன் முந்தைய இயக்கத்திலிருந்து அனைத்து தொகுதி சார்புகளும் மாறவில்லை என்றால், சார்புகளுடன் பணிபுரியும் போது முந்தைய இயக்கத்தின் போது தற்காலிகமாக சேமிக்கப்பட்ட தரவைப் பயன்படுத்தலாம். மாற்றியமைக்கப்பட்ட கோப்புகள் மற்றும் அவற்றைச் சார்ந்திருக்கும் கோப்புகளில் மட்டுமே வகைச் சரிபார்ப்பைச் செய்ய வேண்டும். Mypy இன்னும் சிறிது தூரம் சென்றது: ஒரு தொகுதியின் வெளிப்புற இடைமுகம் மாறவில்லை என்றால், இந்த தொகுதியை இறக்குமதி செய்த மற்ற தொகுதிகள் மீண்டும் சரிபார்க்கப்பட வேண்டியதில்லை என்று mypy கருதுகிறது.
தற்போதுள்ள குறியீட்டின் பெரிய அளவிலான குறிப்புகளை எழுதும் போது, அதிகரிக்கும் சோதனை எங்களுக்கு பெரிதும் உதவியது. குறியீடுடன் சிறுகுறிப்புகள் படிப்படியாக சேர்க்கப்பட்டு, படிப்படியாக மேம்படுத்தப்படுவதால், இந்தச் செயல்முறை பொதுவாக mypy இன் பல செயல்களை உள்ளடக்கியது. மைபியின் முதல் ஓட்டம் இன்னும் மிக மெதுவாக இருந்தது, ஏனெனில் அதில் சரிபார்க்க நிறைய சார்புகள் இருந்தன. பின்னர், நிலைமையை மேம்படுத்த, ரிமோட் கேச்சிங் பொறிமுறையை செயல்படுத்தினோம். உள்ளூர் கேச் காலாவதியாகிவிட்டதாக mypy கண்டறிந்தால், அது மையப்படுத்தப்பட்ட களஞ்சியத்திலிருந்து முழு கோட்பேஸிற்கான தற்போதைய கேச் ஸ்னாப்ஷாட்டைப் பதிவிறக்கும். இந்த ஸ்னாப்ஷாட்டைப் பயன்படுத்தி அது ஒரு கூடுதல் சரிபார்ப்பைச் செய்கிறது. இது மைபியின் செயல்திறனை அதிகரிக்க இன்னும் ஒரு பெரிய படியை எடுத்துள்ளது.
டிராப்பாக்ஸில் வகைச் சரிபார்ப்பை விரைவாகவும் இயல்பாகவும் ஏற்றுக்கொண்ட காலகட்டம் இது. 2016 ஆம் ஆண்டின் இறுதியில், எங்களிடம் ஏற்கனவே 420000 பைதான் குறியீடுகள் வகை சிறுகுறிப்புகளுடன் இருந்தன. பல பயனர்கள் வகை சரிபார்ப்பில் ஆர்வமாக இருந்தனர். மேலும் மேலும் மேம்பாட்டுக் குழுக்கள் டிராப்பாக்ஸ் மைபியைப் பயன்படுத்துகின்றன.
அப்போது எல்லாம் நன்றாக இருந்தது, ஆனால் நாங்கள் இன்னும் நிறைய செய்ய வேண்டியிருந்தது. திட்டத்தின் சிக்கல் பகுதிகளை அடையாளம் காணவும், முதலில் என்ன சிக்கல்களைத் தீர்க்க வேண்டும் என்பதைப் புரிந்துகொள்வதற்காகவும் அவ்வப்போது உள் பயனர் கணக்கெடுப்புகளை மேற்கொள்ளத் தொடங்கினோம் (இந்த நடைமுறை இன்றும் நிறுவனத்தில் பயன்படுத்தப்படுகிறது). மிக முக்கியமானது, அது தெளிவாகியது, இரண்டு பணிகள். முதலில், குறியீட்டின் கூடுதல் வகை கவரேஜ் தேவை, இரண்டாவதாக, வேகமாக வேலை செய்ய மைபி தேவை. மைபியை விரைவுபடுத்துவதற்கும், நிறுவனத் திட்டங்களில் அதைச் செயல்படுத்துவதற்கும் எங்கள் பணி இன்னும் முழுமையடையவில்லை என்பது முற்றிலும் தெளிவாகத் தெரிந்தது. இந்த இரண்டு பணிகளின் முக்கியத்துவத்தை நாங்கள் முழுமையாக அறிந்துள்ளோம், அவற்றைத் தீர்ப்பதில் ஈடுபட்டுள்ளோம்.
அதிக உற்பத்தித்திறன்!
அதிகரிக்கும் சோதனைகள் மைபியை வேகமாக்கியது, ஆனால் கருவி இன்னும் வேகமாக இல்லை. பல அதிகரிக்கும் சோதனைகள் ஒரு நிமிடம் நீடித்தன. இதற்கு காரணம் சுழற்சி முறையில் இறக்குமதியாகும். பைத்தானில் எழுதப்பட்ட பெரிய கோட்பேஸ்களுடன் பணிபுரிந்த எவரையும் இது ஆச்சரியப்படுத்தாது. எங்களிடம் நூற்றுக்கணக்கான தொகுதிகள் உள்ளன, அவை ஒவ்வொன்றும் மறைமுகமாக மற்ற அனைத்தையும் இறக்குமதி செய்தன. இறக்குமதி வளையத்தில் உள்ள ஏதேனும் கோப்பு மாற்றப்பட்டால், mypy அந்த லூப்பில் உள்ள அனைத்து கோப்புகளையும், மேலும் அந்த லூப்பில் இருந்து தொகுதிகளை இறக்குமதி செய்யும் எந்த மாட்யூல்களையும் செயலாக்க வேண்டும். டிராப்பாக்ஸில் நிறைய சிக்கல்களை ஏற்படுத்திய பிரபலமற்ற "சார்பு சிக்கல்" அத்தகைய ஒரு சுழற்சி ஆகும். இந்த அமைப்பில் பல நூறு தொகுதிக்கூறுகள் இருந்தவுடன், நேரடியாகவோ அல்லது மறைமுகமாகவோ, பல சோதனைகள் இறக்குமதி செய்யப்பட்டபோது, அது உற்பத்திக் குறியீட்டிலும் பயன்படுத்தப்பட்டது.
வட்ட சார்புகளை "அவிழ்ப்பதற்கான" சாத்தியத்தை நாங்கள் கருதினோம், ஆனால் அதைச் செய்வதற்கான ஆதாரங்கள் எங்களிடம் இல்லை. எங்களுக்குத் தெரியாத அளவுக்கு அதிகமான குறியீடுகள் இருந்தன. இதன் விளைவாக, நாங்கள் ஒரு மாற்று அணுகுமுறையைக் கொண்டு வந்தோம். "சார்பு சிக்கல்கள்" இருந்தபோதும் மைபியை விரைவாகச் செய்ய முடிவு செய்தோம். mypy டீமானைப் பயன்படுத்தி இந்த இலக்கை அடைந்தோம். டீமான் என்பது இரண்டு சுவாரஸ்யமான அம்சங்களைச் செயல்படுத்தும் ஒரு சர்வர் செயல்முறையாகும். முதலாவதாக, இது முழு கோட்பேஸ் பற்றிய தகவலை நினைவகத்தில் சேமிக்கிறது. ஒவ்வொரு முறையும் நீங்கள் mypy ஐ இயக்கும் போது, ஆயிரக்கணக்கான இறக்குமதி சார்புகளுடன் தொடர்புடைய தற்காலிக சேமிப்பில் உள்ள தரவை ஏற்ற வேண்டியதில்லை. இரண்டாவதாக, அவர் கவனமாக, சிறிய கட்டமைப்பு அலகுகளின் மட்டத்தில், செயல்பாடுகள் மற்றும் பிற நிறுவனங்களுக்கு இடையிலான சார்புகளை பகுப்பாய்வு செய்கிறார். உதாரணமாக, செயல்பாடு என்றால் foo ஒரு செயல்பாட்டை அழைக்கிறது bar, பின்னர் ஒரு சார்பு உள்ளது foo இருந்து bar. ஒரு கோப்பு மாறும்போது, டீமான் முதலில், தனித்தனியாக, மாற்றப்பட்ட கோப்பை மட்டுமே செயலாக்குகிறது. அது பின்னர் அந்த கோப்பில் வெளிப்புறமாக தெரியும் மாற்றங்களை பார்க்கிறது, அதாவது மாற்றப்பட்ட செயல்பாட்டு கையொப்பங்கள். மாற்றியமைக்கப்பட்ட செயல்பாட்டைப் பயன்படுத்தும் செயல்பாடுகளை இருமுறை சரிபார்க்க மட்டுமே இறக்குமதிகள் பற்றிய விரிவான தகவல்களை டீமான் பயன்படுத்துகிறது. பொதுவாக, இந்த அணுகுமுறையுடன், நீங்கள் சில செயல்பாடுகளை சரிபார்க்க வேண்டும்.
அசல் mypy செயல்படுத்தல் ஒரு நேரத்தில் ஒரு கோப்பை செயலாக்குவதில் அதிக கவனம் செலுத்தியதால், இவை அனைத்தையும் செயல்படுத்துவது எளிதானது அல்ல. பல எல்லைக்கோடு சூழ்நிலைகளை நாங்கள் சமாளிக்க வேண்டியிருந்தது, குறியீட்டில் ஏதாவது மாற்றம் ஏற்பட்டால் மீண்டும் மீண்டும் சோதனைகள் தேவைப்படும். எடுத்துக்காட்டாக, ஒரு வகுப்பிற்கு புதிய அடிப்படை வகுப்பு ஒதுக்கப்படும் போது இது நிகழும். நாங்கள் விரும்பியதைச் செய்தவுடன், பெரும்பாலான அதிகரிக்கும் காசோலைகளின் செயலாக்க நேரத்தை சில வினாடிகளாகக் குறைக்க முடிந்தது. இது எங்களுக்கு ஒரு பெரிய வெற்றியாகத் தோன்றியது.
இன்னும் அதிக உற்பத்தித்திறன்!
நான் மேலே விவாதித்த ரிமோட் கேச்சிங்குடன் சேர்ந்து, ஒரு புரோகிராமர் அடிக்கடி டைப் செக்கிங்கை இயக்கும்போது ஏற்படும் சிக்கல்களை மைபி டெமான் முழுமையாக தீர்த்து, குறைந்த எண்ணிக்கையிலான கோப்புகளில் மாற்றங்களைச் செய்கிறது. இருப்பினும், குறைவான சாதகமான பயன்பாட்டு வழக்கில் கணினி செயல்திறன் இன்னும் உகந்ததாக இல்லை. mypy இன் சுத்தமான தொடக்கத்திற்கு 15 நிமிடங்களுக்கு மேல் ஆகலாம். இது நாங்கள் மகிழ்ச்சியாக இருந்ததை விட அதிகமாக இருந்தது. ஒவ்வொரு வாரமும் புரோகிராமர்கள் புதிய குறியீட்டை எழுதுவதும், ஏற்கனவே உள்ள குறியீட்டில் சிறுகுறிப்புகளைச் சேர்ப்பதும் தொடர்ந்ததால் நிலைமை மோசமாகியது. எங்கள் பயனர்கள் இன்னும் அதிக செயல்திறனுக்காக பசியுடன் இருந்தனர், ஆனால் பாதியிலேயே அவர்களை சந்தித்ததில் நாங்கள் மகிழ்ச்சியடைந்தோம்.
mypy தொடர்பான முந்தைய யோசனைகளில் ஒன்றிற்கு திரும்ப முடிவு செய்தோம். அதாவது, பைதான் குறியீட்டை சி குறியீட்டாக மாற்றுவது. Cython (Python இல் எழுதப்பட்ட குறியீட்டை C குறியீட்டிற்கு மொழிபெயர்க்க உங்களை அனுமதிக்கும் ஒரு அமைப்பு) மூலம் பரிசோதனை செய்வது, எங்களுக்குத் தெரியும் எந்த வேகத்தையும் கொடுக்கவில்லை, எனவே எங்கள் சொந்த தொகுப்பியை எழுதும் யோசனையை புதுப்பிக்க முடிவு செய்தோம். mypy codebase (Python இல் எழுதப்பட்டது) ஏற்கனவே தேவையான அனைத்து வகை சிறுகுறிப்புகளையும் கொண்டிருப்பதால், கணினியை விரைவுபடுத்த இந்த சிறுகுறிப்புகளைப் பயன்படுத்த முயற்சிப்பது பயனுள்ளது என்று தோன்றியது. இந்த யோசனையை சோதிக்க நான் விரைவாக ஒரு முன்மாதிரியை உருவாக்கினேன். இது பல்வேறு மைக்ரோ பெஞ்ச்மார்க்குகளில் செயல்திறனில் 10 மடங்குக்கும் அதிகமான அதிகரிப்பைக் காட்டியது. சைத்தானைப் பயன்படுத்தி பைதான் மாட்யூல்களை சி மாட்யூல்களுக்கு தொகுத்து, டைப் சிறுகுறிப்புகளை ரன்-டைம் வகை காசோலைகளாக மாற்றுவது எங்கள் யோசனையாக இருந்தது (பொதுவாக வகை சிறுகுறிப்புகள் இயக்க நேரத்தில் புறக்கணிக்கப்பட்டு வகைச் சரிபார்ப்பு அமைப்புகளால் மட்டுமே பயன்படுத்தப்படும்). பைத்தானில் இருந்து மைபி செயல்படுத்தலை நிலையான முறையில் தட்டச்சு செய்ய வடிவமைக்கப்பட்ட ஒரு மொழியில் மொழிபெயர்க்க நாங்கள் திட்டமிட்டுள்ளோம், அது பைத்தானைப் போலவே தோற்றமளிக்கும் (மற்றும், பெரும்பாலும், வேலை செய்யும்). (இந்த வகையான குறுக்கு மொழி இடம்பெயர்வு mypy திட்டத்தின் ஒரு பாரம்பரியமாகிவிட்டது. அசல் mypy செயல்படுத்தல் அலூரில் எழுதப்பட்டது, பின்னர் ஜாவா மற்றும் பைத்தானின் தொடரியல் கலப்பு இருந்தது).
CPython நீட்டிப்பு API இல் கவனம் செலுத்துவது திட்ட மேலாண்மை திறன்களை இழக்காமல் இருக்க முக்கியமாகும். ஒரு மெய்நிகர் இயந்திரத்தையோ அல்லது mypyக்குத் தேவைப்படும் நூலகங்களையோ நாங்கள் செயல்படுத்த வேண்டியதில்லை. கூடுதலாக, முழு பைதான் சுற்றுச்சூழல் அமைப்பு மற்றும் அனைத்து கருவிகளுக்கும் (பைடெஸ்ட் போன்றவை) இன்னும் அணுகல் இருக்கும். இதன் பொருள், வளர்ச்சியின் போது விளக்கப்பட்ட பைதான் குறியீட்டை நாம் தொடர்ந்து பயன்படுத்தலாம், குறியீடு தொகுக்கக் காத்திருக்காமல், குறியீட்டு மாற்றங்களைச் செய்து அதைச் சோதிக்கும் மிக விரைவான வடிவத்துடன் தொடர்ந்து பணியாற்ற அனுமதிக்கிறது. நாங்கள் இரண்டு நாற்காலிகளில் உட்கார்ந்து ஒரு பெரிய வேலையைச் செய்வது போல் இருந்தது, பேசுவதற்கு, நாங்கள் அதை விரும்பினோம்.
நாங்கள் mypyc என்று அழைக்கப்படும் கம்பைலர் (வகைகளை பகுப்பாய்வு செய்வதற்கு mypy ஐ முன்-முனையாகப் பயன்படுத்துவதால்) மிகவும் வெற்றிகரமான திட்டமாக மாறியது. ஒட்டுமொத்தமாக, தேக்ககமின்றி அடிக்கடி mypy ரன்களுக்கு தோராயமாக 4x வேகத்தை அடைந்துள்ளோம். mypyc திட்டத்தின் மையத்தை உருவாக்க மைக்கேல் சல்லிவன், இவான் லெவ்கிவ்ஸ்கி, ஹக் ஹான் மற்றும் நானும் ஒரு சிறிய குழு 4 காலண்டர் மாதங்கள் எடுத்தது. மைபியை மீண்டும் எழுதுவதற்கு தேவையானதை விட இந்த அளவு வேலை மிகவும் சிறியதாக இருந்தது, எடுத்துக்காட்டாக, C++ அல்லது Go இல். மேலும் வேறு மொழியில் மீண்டும் எழுதும் போது நாம் செய்ய வேண்டியதை விட, திட்டத்தில் மிகக் குறைவான மாற்றங்களைச் செய்ய வேண்டியிருந்தது. மற்ற டிராப்பாக்ஸ் புரோகிராமர்கள் தங்கள் குறியீட்டைத் தொகுக்கவும் வேகப்படுத்தவும் பயன்படுத்தக்கூடிய அளவிற்கு mypyc ஐக் கொண்டு வர முடியும் என்று நாங்கள் நம்புகிறோம்.
இந்த அளவிலான செயல்திறனை அடைய, சில சுவாரஸ்யமான பொறியியல் தீர்வுகளைப் பயன்படுத்த வேண்டியிருந்தது. எனவே, கம்பைலர் வேகமான, குறைந்த-நிலை C கன்ஸ்ட்ரக்ட்களைப் பயன்படுத்தி பல செயல்பாடுகளை விரைவுபடுத்த முடியும். விளக்கப்பட்ட செயல்பாட்டை அழைப்பதை விட அத்தகைய அழைப்பு மிக வேகமாக இருக்கும். அகராதி தேடல்கள் போன்ற சில செயல்பாடுகள், CPython இலிருந்து வழக்கமான C-API அழைப்புகளைப் பயன்படுத்துவதில் ஈடுபட்டுள்ளன, அவை தொகுக்கப்படும்போது ஓரளவு மட்டுமே வேகமாக இருந்தன. விளக்கத்தால் உருவாக்கப்பட்ட கணினியில் கூடுதல் சுமைகளை எங்களால் அகற்ற முடிந்தது, ஆனால் இந்த விஷயத்தில் இது செயல்திறனின் அடிப்படையில் ஒரு சிறிய ஆதாயத்தை மட்டுமே அளித்தது.
மிகவும் பொதுவான "மெதுவான" செயல்பாடுகளை அடையாளம் காண, நாங்கள் குறியீடு விவரக்குறிப்பைச் செய்தோம். இந்தத் தரவைக் கொண்டு, mypyc ஐ மாற்றியமைக்க முயற்சித்தோம், இதனால் இது போன்ற செயல்பாடுகளுக்கு வேகமான C குறியீட்டை உருவாக்கலாம் அல்லது வேகமான செயல்பாடுகளைப் பயன்படுத்தி தொடர்புடைய பைதான் குறியீட்டை மீண்டும் எழுத முயற்சித்தோம் (மேலும் சில சமயங்களில் அந்த அல்லது பிற சிக்கலுக்கு எங்களிடம் போதுமான எளிய தீர்வு இல்லை) . கம்பைலர் தானாகவே அதே உருமாற்றத்தைச் செய்வதைக் காட்டிலும் பைதான் குறியீட்டை மீண்டும் எழுதுவது சிக்கலுக்கு எளிதான தீர்வாகும். நீண்ட காலத்திற்கு, இந்த மாற்றங்களில் பலவற்றை தானியக்கமாக்க விரும்பினோம், ஆனால் அந்த நேரத்தில் நாங்கள் குறைந்த முயற்சியுடன் மைபியை விரைவுபடுத்துவதில் கவனம் செலுத்தினோம். நாங்கள், இந்த இலக்கை நோக்கி நகர்ந்து, பல மூலைகளை வெட்டினோம்.
தொடர வேண்டும் ...
அன்புள்ள வாசகர்கள்! மைபி திட்டம் இருப்பதைப் பற்றி நீங்கள் அறிந்தபோது அதைப் பற்றிய உங்கள் பதிவுகள் என்ன?
ஆதாரம்: www.habr.com