പൈത്തൺ കോഡിന്റെ 4 ദശലക്ഷം ലൈനുകൾ ടൈപ്പ് ചെക്ക് ചെയ്യുന്നതിനുള്ള പാത. ഭാഗം 2

പൈത്തൺ കോഡിന്റെ ദശലക്ഷക്കണക്കിന് വരികൾക്കായി ഡ്രോപ്പ്ബോക്‌സ് എങ്ങനെ തരം നിയന്ത്രണം സംഘടിപ്പിച്ചു എന്നതിനെക്കുറിച്ചുള്ള മെറ്റീരിയലിന്റെ വിവർത്തനത്തിന്റെ രണ്ടാം ഭാഗം ഞങ്ങൾ ഇന്ന് പ്രസിദ്ധീകരിക്കുന്നു.

→ ഒന്നാം ഭാഗം വായിക്കുക

ഔദ്യോഗിക തരം പിന്തുണ (PEP 484)

2014ലെ ഹാക്ക് വീക്കിൽ ഡ്രോപ്പ്‌ബോക്‌സിൽ മൈപിയുമായി ബന്ധപ്പെട്ട ഞങ്ങളുടെ ആദ്യത്തെ ഗുരുതരമായ പരീക്ഷണങ്ങൾ ഞങ്ങൾ നടത്തി. ഡ്രോപ്പ്ബോക്‌സ് ഹോസ്റ്റുചെയ്യുന്ന ഒരാഴ്ചത്തെ ഇവന്റാണ് ഹാക്ക് വീക്ക്. ഈ സമയത്ത്, ജീവനക്കാർക്ക് അവർ ആഗ്രഹിക്കുന്നതെന്തും പ്രവർത്തിക്കാൻ കഴിയും! ഡ്രോപ്പ്‌ബോക്‌സിന്റെ ഏറ്റവും പ്രശസ്തമായ ചില സാങ്കേതിക പദ്ധതികൾ തുടങ്ങിയത് ഇതുപോലുള്ള ഇവന്റുകളിൽ നിന്നാണ്. ഈ പരീക്ഷണത്തിന്റെ ഫലമായി, വ്യാപകമായ ഉപയോഗത്തിന് പദ്ധതി ഇതുവരെ തയ്യാറായിട്ടില്ലെങ്കിലും, mypy പ്രതീക്ഷ നൽകുന്നതാണെന്ന് ഞങ്ങൾ നിഗമനം ചെയ്തു.

അക്കാലത്ത്, പൈത്തൺ ടൈപ്പ് ഹിന്റിങ് സിസ്റ്റങ്ങൾ സ്റ്റാൻഡേർഡൈസ് ചെയ്യുക എന്ന ആശയം അന്തരീക്ഷത്തിലായിരുന്നു. ഞാൻ പറഞ്ഞതുപോലെ, പൈത്തൺ 3.0 മുതൽ ഫംഗ്‌ഷനുകൾക്കായി ടൈപ്പ് വ്യാഖ്യാനങ്ങൾ ഉപയോഗിക്കുന്നത് സാധ്യമായിരുന്നു, എന്നാൽ ഇവ നിർവചിക്കപ്പെട്ട വാക്യഘടനയും സെമാന്റിക്‌സും ഇല്ലാതെ ഏകപക്ഷീയമായ പദപ്രയോഗങ്ങൾ മാത്രമായിരുന്നു. പ്രോഗ്രാം നിർവ്വഹണ സമയത്ത്, ഈ വ്യാഖ്യാനങ്ങൾ മിക്കവാറും അവഗണിക്കപ്പെട്ടു. ഹാക്ക് വീക്കിന് ശേഷം, ഞങ്ങൾ സെമാന്റിക്‌സ് സ്റ്റാൻഡേർഡൈസ് ചെയ്യുന്നതിനായി പ്രവർത്തിക്കാൻ തുടങ്ങി. ഈ പ്രവൃത്തിയാണ് ആവിർഭാവത്തിലേക്ക് നയിച്ചത് PEP 484 (Guido van Rossum, Łukasz Langa എന്നിവരും ഞാനും ഈ പ്രമാണത്തിൽ സഹകരിച്ചു).

ഞങ്ങളുടെ ഉദ്ദേശ്യങ്ങൾ രണ്ട് വശങ്ങളിൽ നിന്ന് വീക്ഷിക്കാനാകും. ആദ്യം, മുഴുവൻ പൈത്തൺ ഇക്കോസിസ്റ്റത്തിനും ടൈപ്പ് സൂചനകൾ ഉപയോഗിക്കുന്നതിന് പൊതുവായ ഒരു സമീപനം സ്വീകരിക്കാൻ കഴിയുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിച്ചു (പൈത്തണിൽ "തരം വ്യാഖ്യാനങ്ങൾക്ക്" തുല്യമായ പദം). സാധ്യമായ അപകടസാധ്യതകൾ കണക്കിലെടുക്കുമ്പോൾ, പരസ്പര വിരുദ്ധമായ പല സമീപനങ്ങളും ഉപയോഗിക്കുന്നതിനേക്കാൾ മികച്ചതായിരിക്കും ഇത്. രണ്ടാമതായി, പൈത്തൺ കമ്മ്യൂണിറ്റിയിലെ നിരവധി അംഗങ്ങളുമായി ടൈപ്പ് വ്യാഖ്യാന സംവിധാനങ്ങളെക്കുറിച്ച് തുറന്ന് ചർച്ച ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. പൈത്തൺ പ്രോഗ്രാമർമാരുടെ വിശാലമായ ജനങ്ങളുടെ കണ്ണിൽ ഭാഷയുടെ അടിസ്ഥാന ആശയങ്ങളിൽ നിന്ന് "വിശ്വാസത്യാഗികൾ" ആയി കാണപ്പെടാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല എന്ന വസ്തുതയാണ് ഈ ആഗ്രഹം ഭാഗികമായി നിർദ്ദേശിച്ചത്. "ഡക്ക് ടൈപ്പിംഗ്" എന്നറിയപ്പെടുന്ന ചലനാത്മകമായി ടൈപ്പ് ചെയ്ത ഭാഷയാണിത്. കമ്മ്യൂണിറ്റിയിൽ, തുടക്കത്തിൽ തന്നെ, സ്റ്റാറ്റിക് ടൈപ്പിംഗ് എന്ന ആശയത്തോട് അൽപ്പം സംശയാസ്പദമായ മനോഭാവം ഉണ്ടാകാതിരിക്കാൻ കഴിഞ്ഞില്ല. എന്നാൽ സ്റ്റാറ്റിക് ടൈപ്പിംഗ് നിർബന്ധമല്ലെന്ന് വ്യക്തമായതിന് ശേഷം (അത് യഥാർത്ഥത്തിൽ ഉപയോഗപ്രദമാണെന്ന് ആളുകൾ മനസ്സിലാക്കിയതിന് ശേഷം) ആ വികാരം ക്രമേണ കുറഞ്ഞു.

ഒടുവിൽ സ്വീകരിച്ച ടൈപ്പ് സൂചന വാക്യഘടന, അക്കാലത്ത് mypy പിന്തുണച്ചതിന് സമാനമാണ്. 484-ൽ പൈത്തൺ 3.5-നൊപ്പം PEP 2015 പുറത്തിറങ്ങി. പൈത്തൺ ഇപ്പോൾ ചലനാത്മകമായി ടൈപ്പ് ചെയ്ത ഭാഷയായിരുന്നില്ല. ഈ സംഭവത്തെ പൈത്തൺ ചരിത്രത്തിലെ ഒരു സുപ്രധാന നാഴികക്കല്ലായി കരുതാനാണ് എനിക്കിഷ്ടം.

കുടിയേറ്റത്തിന്റെ തുടക്കം

2015 അവസാനത്തോടെ, Mypy-യിൽ പ്രവർത്തിക്കാൻ ഡ്രോപ്പ്ബോക്സ് മൂന്ന് ആളുകളുടെ ഒരു ടീമിനെ സൃഷ്ടിച്ചു. അവരിൽ ഗൈഡോ വാൻ റോസ്സം, ഗ്രെഗ് പ്രൈസ്, ഡേവിഡ് ഫിഷർ എന്നിവരും ഉൾപ്പെടുന്നു. ആ നിമിഷം മുതൽ, സ്ഥിതി വളരെ വേഗത്തിൽ വികസിക്കാൻ തുടങ്ങി. മൈപിയുടെ വളർച്ചയ്ക്ക് ആദ്യ തടസ്സം പ്രകടനമായിരുന്നു. ഞാൻ മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, പ്രോജക്റ്റിന്റെ ആദ്യ ദിവസങ്ങളിൽ, mypy നടപ്പിലാക്കൽ C യിലേക്ക് വിവർത്തനം ചെയ്യുന്നതിനെക്കുറിച്ച് ഞാൻ ചിന്തിച്ചു, എന്നാൽ ഈ ആശയം ഇപ്പോൾ പട്ടികയിൽ നിന്ന് പുറത്തായി. mypy പോലുള്ള ഉപകരണങ്ങൾക്ക് വേണ്ടത്ര വേഗതയില്ലാത്ത CPython ഇന്റർപ്രെറ്റർ ഉപയോഗിച്ച് സിസ്റ്റം പ്രവർത്തിപ്പിക്കുന്നതിൽ ഞങ്ങൾ കുടുങ്ങി. (ഒരു JIT കംപൈലർ ഉപയോഗിച്ചുള്ള ഇതര പൈത്തൺ നിർവ്വഹണമായ PyPy പദ്ധതിയും ഞങ്ങളെ സഹായിച്ചില്ല.)

ഭാഗ്യവശാൽ, ചില അൽഗോരിതം മെച്ചപ്പെടുത്തലുകൾ ഇവിടെ ഞങ്ങളുടെ സഹായത്തിന് എത്തിയിട്ടുണ്ട്. ആദ്യത്തെ ശക്തമായ "ആക്സിലറേറ്റർ" ഇൻക്രിമെന്റൽ ചെക്കിംഗ് നടപ്പിലാക്കുകയായിരുന്നു. ഈ മെച്ചപ്പെടുത്തലിനു പിന്നിലെ ആശയം വളരെ ലളിതമാണ്: mypy-ന്റെ മുമ്പത്തെ റൺ മുതൽ മൊഡ്യൂളിന്റെ എല്ലാ ഡിപൻഡൻസികളും മാറിയിട്ടില്ലെങ്കിൽ, ഡിപൻഡൻസികളിൽ പ്രവർത്തിക്കുമ്പോൾ മുമ്പത്തെ റൺ സമയത്ത് കാഷെ ചെയ്‌ത ഡാറ്റ നമുക്ക് ഉപയോഗിക്കാം. പരിഷ്‌ക്കരിച്ച ഫയലുകളിലും അവയെ ആശ്രയിച്ചുള്ള ഫയലുകളിലും ടൈപ്പ് ചെക്കിംഗ് മാത്രമേ ഞങ്ങൾക്ക് നടത്തേണ്ടതുള്ളൂ. മൈപി കുറച്ചുകൂടി മുന്നോട്ട് പോയി: ഒരു മൊഡ്യൂളിന്റെ ബാഹ്യ ഇന്റർഫേസ് മാറിയില്ലെങ്കിൽ, ഈ മൊഡ്യൂൾ ഇറക്കുമതി ചെയ്ത മറ്റ് മൊഡ്യൂളുകൾ വീണ്ടും പരിശോധിക്കേണ്ടതില്ലെന്ന് mypy അനുമാനിച്ചു.

നിലവിലുള്ള കോഡിന്റെ വലിയ അളവുകൾ വ്യാഖ്യാനിക്കുമ്പോൾ ഇൻക്രിമെന്റൽ ചെക്കിംഗ് ഞങ്ങളെ വളരെയധികം സഹായിച്ചിട്ടുണ്ട്. വ്യാഖ്യാനങ്ങൾ കോഡിലേക്ക് ക്രമേണ ചേർക്കുകയും ക്രമേണ മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്നതിനാൽ, ഈ പ്രക്രിയയിൽ സാധാരണയായി മൈപിയുടെ നിരവധി ആവർത്തന റണ്ണുകൾ ഉൾപ്പെടുന്നു എന്നതാണ് കാര്യം. മൈപിയുടെ ആദ്യ ഓട്ടം ഇപ്പോഴും വളരെ മന്ദഗതിയിലായിരുന്നു, കാരണം ഇതിന് പരിശോധിക്കാൻ ധാരാളം ഡിപൻഡൻസികൾ ഉണ്ടായിരുന്നു. തുടർന്ന്, സാഹചര്യം മെച്ചപ്പെടുത്തുന്നതിന്, ഞങ്ങൾ ഒരു റിമോട്ട് കാഷിംഗ് സംവിധാനം നടപ്പിലാക്കി. ലോക്കൽ കാഷെ കാലഹരണപ്പെടാൻ സാധ്യതയുണ്ടെന്ന് mypy കണ്ടെത്തിയാൽ, അത് കേന്ദ്രീകൃത ശേഖരത്തിൽ നിന്ന് മുഴുവൻ കോഡ്ബേസിനും നിലവിലുള്ള കാഷെ സ്നാപ്പ്ഷോട്ട് ഡൗൺലോഡ് ചെയ്യുന്നു. ഈ സ്നാപ്പ്ഷോട്ട് ഉപയോഗിച്ച് അത് ഒരു ഇൻക്രിമെന്റൽ പരിശോധന നടത്തുന്നു. ഇത് മൈപിയുടെ പ്രകടനം വർധിപ്പിക്കുന്നതിനുള്ള ഒരു വലിയ ചുവടുവെപ്പ് കൂടി ഞങ്ങളെ എത്തിച്ചു.

ഡ്രോപ്പ്ബോക്സിൽ ടൈപ്പ് ചെക്കിംഗ് വേഗത്തിലും സ്വാഭാവികമായും സ്വീകരിച്ച കാലഘട്ടമായിരുന്നു ഇത്. 2016 അവസാനത്തോടെ, ടൈപ്പ് വ്യാഖ്യാനങ്ങളുള്ള പൈത്തൺ കോഡിന്റെ ഏകദേശം 420000 ലൈനുകൾ ഞങ്ങളുടെ പക്കലുണ്ടായിരുന്നു. പല ഉപയോക്താക്കളും ടൈപ്പ് ചെക്കിംഗിൽ ആവേശഭരിതരായിരുന്നു. കൂടുതൽ കൂടുതൽ വികസന ടീമുകൾ Dropbox mypy ഉപയോഗിക്കുന്നു.

അപ്പോൾ എല്ലാം നല്ലതായി കാണപ്പെട്ടു, പക്ഷേ ഞങ്ങൾക്ക് ഇനിയും ഒരുപാട് കാര്യങ്ങൾ ചെയ്യാനുണ്ടായിരുന്നു. പ്രോജക്‌റ്റിന്റെ പ്രശ്‌ന മേഖലകൾ തിരിച്ചറിയുന്നതിനും ആദ്യം പരിഹരിക്കേണ്ട പ്രശ്‌നങ്ങൾ ഏതെന്ന് മനസ്സിലാക്കുന്നതിനുമായി ഞങ്ങൾ ഇടയ്‌ക്കിടെ ആന്തരിക ഉപയോക്തൃ സർവേകൾ നടത്താൻ തുടങ്ങി (ഈ രീതി ഇന്നും കമ്പനിയിൽ ഉപയോഗിക്കുന്നു). ഏറ്റവും പ്രധാനപ്പെട്ടത്, വ്യക്തമായത് പോലെ, രണ്ട് ജോലികൾ ആയിരുന്നു. ആദ്യം, ഞങ്ങൾക്ക് കോഡിന്റെ കൂടുതൽ തരം കവറേജ് ആവശ്യമാണ്, രണ്ടാമതായി, വേഗത്തിൽ പ്രവർത്തിക്കാൻ ഞങ്ങൾക്ക് mypy ആവശ്യമാണ്. Mypy വേഗത്തിലാക്കാനും കമ്പനി പ്രോജക്‌ടുകളിൽ അത് നടപ്പിലാക്കാനുമുള്ള ഞങ്ങളുടെ പ്രവർത്തനങ്ങൾ ഇപ്പോഴും പൂർത്തിയായിട്ടില്ലെന്ന് വ്യക്തമായിരുന്നു. ഈ രണ്ട് ജോലികളുടെയും പ്രാധാന്യത്തെക്കുറിച്ച് പൂർണ്ണമായി ബോധവാനായ ഞങ്ങൾ അവ പരിഹരിക്കാൻ തുടങ്ങി.

കൂടുതൽ ഉൽപ്പാദനക്ഷമത!

ഇൻക്രിമെന്റൽ പരിശോധനകൾ mypy വേഗത്തിലാക്കി, പക്ഷേ ടൂൾ അപ്പോഴും വേണ്ടത്ര വേഗതയുള്ളതായിരുന്നില്ല. നിരവധി ഇൻക്രിമെന്റൽ പരിശോധനകൾ ഒരു മിനിറ്റോളം നീണ്ടുനിന്നു. ചാക്രികമായ ഇറക്കുമതിയായിരുന്നു ഇതിന് കാരണം. പൈത്തണിൽ എഴുതിയ വലിയ കോഡ്ബേസുകളിൽ പ്രവർത്തിച്ച ആരെയും ഇത് ഒരുപക്ഷേ അത്ഭുതപ്പെടുത്തില്ല. നൂറുകണക്കിന് മൊഡ്യൂളുകളുടെ സെറ്റുകൾ ഞങ്ങളുടെ പക്കലുണ്ടായിരുന്നു, അവയിൽ ഓരോന്നും പരോക്ഷമായി മറ്റുള്ളവയെല്ലാം ഇറക്കുമതി ചെയ്തു. ഒരു ഇംപോർട്ട് ലൂപ്പിലെ ഏതെങ്കിലും ഫയൽ മാറ്റിയാൽ, ആ ലൂപ്പിലെ എല്ലാ ഫയലുകളും, ആ ലൂപ്പിൽ നിന്ന് മൊഡ്യൂളുകൾ ഇറക്കുമതി ചെയ്യുന്ന മൊഡ്യൂളുകളും mypy പ്രോസസ്സ് ചെയ്യേണ്ടതുണ്ട്. ഡ്രോപ്പ്‌ബോക്‌സിൽ വളരെയധികം പ്രശ്‌നങ്ങൾക്ക് കാരണമായ കുപ്രസിദ്ധമായ "ആശ്രിതത്വ കുരുക്ക്" അത്തരത്തിലുള്ള ഒരു ചക്രം ആയിരുന്നു. ഈ ഘടനയിൽ നൂറുകണക്കിന് മൊഡ്യൂളുകൾ അടങ്ങിയിരിക്കുമ്പോൾ, നേരിട്ടോ അല്ലാതെയോ നിരവധി പരിശോധനകൾ ഇറക്കുമതി ചെയ്യുമ്പോൾ, അത് പ്രൊഡക്ഷൻ കോഡിലും ഉപയോഗിച്ചിരുന്നു.

വൃത്താകൃതിയിലുള്ള ഡിപൻഡൻസികൾ "അഴിച്ചുമാറ്റാനുള്ള" സാധ്യത ഞങ്ങൾ പരിഗണിച്ചു, പക്ഷേ അത് ചെയ്യാനുള്ള വിഭവങ്ങൾ ഞങ്ങളുടെ പക്കലില്ലായിരുന്നു. ഞങ്ങൾക്ക് പരിചിതമല്ലാത്ത വളരെയധികം കോഡുകൾ ഉണ്ടായിരുന്നു. തൽഫലമായി, ഞങ്ങൾ ഒരു ബദൽ സമീപനം കൊണ്ടുവന്നു. "ആശ്രിതത്വത്തിന്റെ" സാന്നിധ്യത്തിൽ പോലും mypy വേഗത്തിൽ പ്രവർത്തിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. mypy ഡെമൺ ഉപയോഗിച്ചാണ് ഞങ്ങൾ ഈ ലക്ഷ്യം നേടിയത്. രണ്ട് രസകരമായ കഴിവുകൾ നടപ്പിലാക്കുന്ന ഒരു സെർവർ പ്രക്രിയയാണ് ഡെമൺ. ഒന്നാമതായി, ഇത് മുഴുവൻ കോഡ്ബേസിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ മെമ്മറിയിൽ സംഭരിക്കുന്നു. ഇതിനർത്ഥം നിങ്ങൾ mypy പ്രവർത്തിപ്പിക്കുമ്പോഴെല്ലാം, ആയിരക്കണക്കിന് ഇറക്കുമതി ചെയ്ത ഡിപൻഡൻസികളുമായി ബന്ധപ്പെട്ട കാഷെ ചെയ്ത ഡാറ്റ ലോഡ് ചെയ്യേണ്ടതില്ല എന്നാണ്. രണ്ടാമതായി, ചെറിയ ഘടനാപരമായ യൂണിറ്റുകളുടെ തലത്തിൽ, ഫംഗ്ഷനുകളും മറ്റ് എന്റിറ്റികളും തമ്മിലുള്ള ആശ്രിതത്വത്തെ അദ്ദേഹം ശ്രദ്ധാപൂർവ്വം വിശകലനം ചെയ്യുന്നു. ഉദാഹരണത്തിന്, ഫംഗ്ഷൻ ആണെങ്കിൽ foo ഒരു ഫംഗ്ഷൻ വിളിക്കുന്നു bar, അപ്പോൾ ഒരു ആശ്രിതത്വം ഉണ്ട് foo от bar. ഒരു ഫയൽ മാറുമ്പോൾ, ഡെമൺ ആദ്യം, ഐസൊലേഷനിൽ, മാറ്റിയ ഫയൽ മാത്രം പ്രോസസ്സ് ചെയ്യുന്നു. അത് പിന്നീട് ആ ഫയലിൽ ബാഹ്യമായി ദൃശ്യമാകുന്ന മാറ്റങ്ങളെ നോക്കുന്നു, അതായത് മാറ്റിയ ഫംഗ്ഷൻ സിഗ്നേച്ചറുകൾ. യഥാർത്ഥത്തിൽ പരിഷ്‌ക്കരിച്ച ഫംഗ്‌ഷൻ ഉപയോഗിക്കുന്ന ഫംഗ്‌ഷനുകൾ രണ്ടുതവണ പരിശോധിക്കാൻ മാത്രമാണ് ഡെമൺ ഇറക്കുമതിയെക്കുറിച്ചുള്ള വിശദമായ വിവരങ്ങൾ ഉപയോഗിക്കുന്നത്. സാധാരണയായി, ഈ സമീപനത്തിലൂടെ, നിങ്ങൾ വളരെ കുറച്ച് ഫംഗ്ഷനുകൾ പരിശോധിക്കേണ്ടതുണ്ട്.

ഇവയെല്ലാം നടപ്പിലാക്കുന്നത് എളുപ്പമായിരുന്നില്ല, കാരണം യഥാർത്ഥ mypy നടപ്പിലാക്കൽ ഒരു സമയം ഒരു ഫയൽ പ്രോസസ്സ് ചെയ്യുന്നതിൽ വളരെയധികം ശ്രദ്ധ കേന്ദ്രീകരിച്ചിരുന്നു. കോഡിൽ എന്തെങ്കിലും മാറ്റം വരുത്തിയ സന്ദർഭങ്ങളിൽ ആവർത്തിച്ചുള്ള പരിശോധനകൾ ആവശ്യമായ നിരവധി ബോർഡർലൈൻ സാഹചര്യങ്ങൾ ഞങ്ങൾക്ക് നേരിടേണ്ടി വന്നു. ഉദാഹരണത്തിന്, ഒരു ക്ലാസിന് ഒരു പുതിയ അടിസ്ഥാന ക്ലാസ് നൽകുമ്പോൾ ഇത് സംഭവിക്കുന്നു. ഞങ്ങൾ ആഗ്രഹിച്ചത് ചെയ്‌തുകഴിഞ്ഞാൽ, മിക്ക ഇൻക്രിമെന്റൽ ചെക്കുകളുടെയും എക്‌സിക്യൂഷൻ സമയം കുറച്ച് സെക്കന്റുകളായി കുറയ്ക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. ഇതൊരു വലിയ വിജയമായി ഞങ്ങൾക്ക് തോന്നി.

ഇതിലും കൂടുതൽ ഉൽപ്പാദനക്ഷമത!

ഞാൻ മുകളിൽ ചർച്ച ചെയ്ത റിമോട്ട് കാഷിംഗിനൊപ്പം, ഒരു പ്രോഗ്രാമർ ഇടയ്ക്കിടെ ടൈപ്പ് ചെക്കിംഗ് നടത്തുമ്പോൾ ഉണ്ടാകുന്ന പ്രശ്നങ്ങൾ mypy ഡെമൺ പൂർണ്ണമായും പരിഹരിച്ചു, ചെറിയ എണ്ണം ഫയലുകളിൽ മാറ്റങ്ങൾ വരുത്തുന്നു. എന്നിരുന്നാലും, ഏറ്റവും കുറഞ്ഞ അനുകൂല ഉപയോഗ കേസിൽ സിസ്റ്റം പ്രകടനം ഇപ്പോഴും ഒപ്റ്റിമലിൽ നിന്ന് വളരെ അകലെയായിരുന്നു. മൈപിയുടെ വൃത്തിയുള്ള സ്റ്റാർട്ടപ്പിന് 15 മിനിറ്റിലധികം എടുത്തേക്കാം. ഞങ്ങൾ സന്തോഷിക്കുമായിരുന്നതിനേക്കാൾ വളരെ കൂടുതലായിരുന്നു ഇത്. പ്രോഗ്രാമർമാർ പുതിയ കോഡ് എഴുതുന്നതും നിലവിലുള്ള കോഡിലേക്ക് വ്യാഖ്യാനങ്ങൾ ചേർക്കുന്നതും തുടർന്നതിനാൽ ഓരോ ആഴ്ചയും സ്ഥിതി കൂടുതൽ വഷളായി. കൂടുതൽ പ്രകടനത്തിനായി ഞങ്ങളുടെ ഉപയോക്താക്കൾക്ക് അപ്പോഴും വിശക്കുന്നുണ്ടായിരുന്നു, എന്നാൽ പാതിവഴിയിൽ അവരെ കണ്ടുമുട്ടിയതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട്.

മൈപിയെ സംബന്ധിച്ച മുൻ ആശയങ്ങളിലൊന്നിലേക്ക് മടങ്ങാൻ ഞങ്ങൾ തീരുമാനിച്ചു. അതായത്, പൈത്തൺ കോഡ് സി കോഡാക്കി മാറ്റാൻ. Cython (പൈത്തണിൽ എഴുതിയിരിക്കുന്ന കോഡ് C കോഡിലേക്ക് വിവർത്തനം ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു സിസ്റ്റം) ഉപയോഗിച്ച് പരീക്ഷിക്കുന്നത് ഞങ്ങൾക്ക് ദൃശ്യമായ വേഗതയൊന്നും നൽകിയില്ല, അതിനാൽ ഞങ്ങളുടെ സ്വന്തം കംപൈലർ എഴുതുക എന്ന ആശയം പുനരുജ്ജീവിപ്പിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. mypy കോഡ്ബേസിൽ (പൈത്തണിൽ എഴുതിയത്) ആവശ്യമായ എല്ലാ തരം വ്യാഖ്യാനങ്ങളും ഇതിനകം അടങ്ങിയിരിക്കുന്നതിനാൽ, സിസ്റ്റം വേഗത്തിലാക്കാൻ ഈ വ്യാഖ്യാനങ്ങൾ ഉപയോഗിക്കുന്നത് മൂല്യവത്തായിരിക്കുമെന്ന് ഞങ്ങൾ കരുതി. ഈ ആശയം പരിശോധിക്കാൻ ഞാൻ പെട്ടെന്ന് ഒരു പ്രോട്ടോടൈപ്പ് സൃഷ്ടിച്ചു. വിവിധ മൈക്രോ ബെഞ്ച്മാർക്കുകളിലെ പ്രകടനത്തിൽ ഇത് 10 മടങ്ങ് വർദ്ധന കാണിച്ചു. സൈത്തൺ ഉപയോഗിച്ച് പൈത്തൺ മൊഡ്യൂളുകൾ സി മൊഡ്യൂളുകളിലേക്ക് കംപൈൽ ചെയ്യുക, കൂടാതെ ടൈപ്പ് വ്യാഖ്യാനങ്ങളെ റൺ-ടൈം ടൈപ്പ് ചെക്കുകളാക്കി മാറ്റുക എന്നതായിരുന്നു ഞങ്ങളുടെ ആശയം (സാധാരണയായി ടൈപ്പ് വ്യാഖ്യാനങ്ങൾ റൺ-ടൈമിൽ അവഗണിക്കുകയും ടൈപ്പ് ചെക്കിംഗ് സിസ്റ്റങ്ങൾ മാത്രം ഉപയോഗിക്കുകയും ചെയ്യും). പൈത്തണിൽ നിന്നുള്ള mypy നടപ്പിലാക്കൽ, സ്ഥിരമായി ടൈപ്പ് ചെയ്യാൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഒരു ഭാഷയിലേക്ക് വിവർത്തനം ചെയ്യാൻ ഞങ്ങൾ പദ്ധതിയിട്ടിരുന്നു, അത് പൈത്തണിനെപ്പോലെ തന്നെ കാണപ്പെടും (കൂടുതലും, മിക്കവാറും പ്രവർത്തിക്കും). (ഇത്തരത്തിലുള്ള ക്രോസ്-ലാംഗ്വേജ് മൈഗ്രേഷൻ മൈപി പ്രോജക്റ്റിന്റെ ഒരു പാരമ്പര്യമായി മാറിയിരിക്കുന്നു. യഥാർത്ഥ മൈപി നടപ്പിലാക്കൽ ആലൂരിൽ എഴുതിയതാണ്, തുടർന്ന് ജാവയുടെയും പൈത്തണിന്റെയും ഒരു വാക്യഘടന ഹൈബ്രിഡ് ഉണ്ടായിരുന്നു).

CPython എക്സ്റ്റൻഷൻ API-യിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത് പ്രോജക്ട് മാനേജ്‌മെന്റ് കഴിവുകൾ നഷ്‌ടപ്പെടാതിരിക്കാൻ പ്രധാനമായിരുന്നു. ഞങ്ങൾക്ക് ഒരു വെർച്വൽ മെഷീനോ മൈപിക്ക് ആവശ്യമായ ഏതെങ്കിലും ലൈബ്രറിയോ നടപ്പിലാക്കേണ്ടതില്ല. കൂടാതെ, മുഴുവൻ പൈത്തൺ ഇക്കോസിസ്റ്റത്തിലേക്കും എല്ലാ ഉപകരണങ്ങളിലേക്കും (പൈറ്റെസ്റ്റ് പോലുള്ളവ) ഞങ്ങൾക്ക് തുടർന്നും ആക്സസ് ഉണ്ടായിരിക്കും. ഇതിനർത്ഥം, വികസന സമയത്ത് വ്യാഖ്യാനിച്ച പൈത്തൺ കോഡ് ഉപയോഗിക്കുന്നത് തുടരാം, കോഡ് കംപൈൽ ചെയ്യുന്നതിനായി കാത്തിരിക്കുന്നതിനുപകരം, കോഡ് മാറ്റങ്ങൾ വരുത്തുന്നതിനും അത് പരിശോധിക്കുന്നതിനുമുള്ള വളരെ വേഗത്തിലുള്ള പാറ്റേൺ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു. ഞങ്ങൾ രണ്ട് കസേരകളിൽ ഇരിക്കുന്ന ഒരു മികച്ച ജോലി ചെയ്യുന്നതായി തോന്നി, അങ്ങനെ പറഞ്ഞാൽ, ഞങ്ങൾ അത് ഇഷ്ടപ്പെട്ടു.

ഞങ്ങൾ mypyc എന്ന് വിളിക്കുന്ന കംപൈലർ (ഇത് തരങ്ങൾ വിശകലനം ചെയ്യുന്നതിനുള്ള മുൻഭാഗമായി mypy ഉപയോഗിക്കുന്നതിനാൽ) വളരെ വിജയകരമായ ഒരു പ്രോജക്റ്റായി മാറി. മൊത്തത്തിൽ, കാഷെ ചെയ്യാതെയുള്ള പതിവ് mypy റണ്ണുകൾക്കായി ഞങ്ങൾ ഏകദേശം 4x വേഗത കൈവരിച്ചു. മൈക്കിൾ സള്ളിവൻ, ഇവാൻ ലെവ്കിവ്സ്കി, ഹ്യൂ ഹാൻ, പിന്നെ ഞാനും ഉൾപ്പെട്ട ഒരു ചെറിയ സംഘം മൈപിക് പ്രോജക്റ്റിന്റെ കാതൽ വികസിപ്പിക്കുന്നതിന് ഏകദേശം 4 കലണ്ടർ മാസങ്ങൾ എടുത്തു. mypy മാറ്റിയെഴുതാൻ ആവശ്യമായതിനേക്കാൾ വളരെ ചെറുതായിരുന്നു ഈ ജോലിയുടെ അളവ്, ഉദാഹരണത്തിന്, C++ അല്ലെങ്കിൽ Go-ൽ. പ്രോജക്റ്റ് മറ്റൊരു ഭാഷയിൽ വീണ്ടും എഴുതുമ്പോൾ വരുത്തേണ്ടതിനേക്കാൾ വളരെ കുറച്ച് മാറ്റങ്ങൾ മാത്രമേ ഞങ്ങൾക്ക് വരുത്തേണ്ടതുള്ളൂ. മറ്റ് ഡ്രോപ്പ്ബോക്സ് പ്രോഗ്രാമർമാർക്ക് അവരുടെ കോഡ് കംപൈൽ ചെയ്യാനും വേഗത്തിലാക്കാനും ഇത് ഉപയോഗിക്കാവുന്ന തരത്തിലേക്ക് mypyc കൊണ്ടുവരാൻ കഴിയുമെന്നും ഞങ്ങൾ പ്രതീക്ഷിച്ചു.

ഈ നിലവാരത്തിലുള്ള പ്രകടനം നേടുന്നതിന്, ഞങ്ങൾ രസകരമായ ചില എഞ്ചിനീയറിംഗ് പരിഹാരങ്ങൾ പ്രയോഗിക്കേണ്ടതുണ്ട്. അങ്ങനെ, കംപൈലറിന് വേഗതയേറിയതും താഴ്ന്ന നിലയിലുള്ളതുമായ C നിർമ്മിതികൾ ഉപയോഗിച്ച് പല പ്രവർത്തനങ്ങളും വേഗത്തിലാക്കാൻ കഴിയും.ഉദാഹരണത്തിന്, ഒരു കംപൈൽ ചെയ്ത ഫംഗ്ഷൻ കോൾ ഒരു C ഫംഗ്ഷൻ കോളിലേക്ക് വിവർത്തനം ചെയ്യപ്പെടുന്നു. വ്യാഖ്യാനിച്ച ഫംഗ്‌ഷനെ വിളിക്കുന്നതിനേക്കാൾ വളരെ വേഗതയുള്ളതാണ് അത്തരമൊരു കോൾ. നിഘണ്ടു ലുക്കപ്പുകൾ പോലെയുള്ള ചില പ്രവർത്തനങ്ങൾ ഇപ്പോഴും CPython-ൽ നിന്നുള്ള പതിവ് C-API കോളുകൾ ഉപയോഗിക്കുന്നു, അവ കംപൈൽ ചെയ്യുമ്പോൾ നേരിയ വേഗത്തിലായിരുന്നു. വ്യാഖ്യാനത്തിലൂടെ സൃഷ്ടിച്ച സിസ്റ്റത്തിലെ അധിക ലോഡ് ഇല്ലാതാക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു, എന്നാൽ ഈ സാഹചര്യത്തിൽ ഇത് പ്രകടനത്തിന്റെ കാര്യത്തിൽ ഒരു ചെറിയ നേട്ടം മാത്രമാണ് നൽകിയത്.

ഏറ്റവും സാധാരണമായ "സ്ലോ" പ്രവർത്തനങ്ങൾ തിരിച്ചറിയാൻ, ഞങ്ങൾ കോഡ് പ്രൊഫൈലിംഗ് നടത്തി. ഈ ഡാറ്റ ഉപയോഗിച്ച് സായുധരായ ഞങ്ങൾ ഒന്നുകിൽ mypyc മാറ്റാൻ ശ്രമിച്ചു, അതുവഴി അത്തരം പ്രവർത്തനങ്ങൾക്ക് വേഗതയേറിയ C കോഡ് സൃഷ്‌ടിക്കാം, അല്ലെങ്കിൽ വേഗത്തിലുള്ള പ്രവർത്തനങ്ങൾ ഉപയോഗിച്ച് അനുബന്ധ പൈത്തൺ കോഡ് മാറ്റിയെഴുതുക (ചിലപ്പോൾ അതിനോ മറ്റ് പ്രശ്‌നങ്ങൾക്കോ ​​വേണ്ടത്ര ലളിതമായ പരിഹാരം ഞങ്ങൾക്കില്ല) . കംപൈലർ സ്വയമേവ ഒരേ പരിവർത്തനം നടത്തുന്നതിനേക്കാൾ പൈത്തൺ കോഡ് വീണ്ടും എഴുതുന്നത് പ്രശ്നത്തിന് എളുപ്പമുള്ള ഒരു പരിഹാരമായിരുന്നു. ദീർഘകാലാടിസ്ഥാനത്തിൽ, ഈ പരിവർത്തനങ്ങളിൽ പലതും യാന്ത്രികമാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു, എന്നാൽ ആ സമയത്ത് ഞങ്ങൾ കുറഞ്ഞ പരിശ്രമത്തിലൂടെ mypy വേഗത്തിലാക്കുന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു. ഈ ലക്ഷ്യത്തിലേക്ക് നീങ്ങുമ്പോൾ, ഞങ്ങൾ നിരവധി കോണുകൾ മുറിച്ചു.

തുടരേണ്ടത് ...

പ്രിയ വായനക്കാർ! മൈപി പ്രോജക്‌റ്റിന്റെ അസ്തിത്വത്തെക്കുറിച്ച് അറിഞ്ഞപ്പോൾ അതിനെക്കുറിച്ചുള്ള നിങ്ങളുടെ മതിപ്പ് എന്തായിരുന്നു?

അവലംബം: www.habr.com