პითონის კოდის 4 მილიონი ხაზის აკრეფის გზა. Ნაწილი 2

დღეს ჩვენ ვაქვეყნებთ მასალის თარგმანის მეორე ნაწილს იმის შესახებ, თუ როგორ მოაწყო Dropbox-მა პითონის კოდის რამდენიმე მილიონი ხაზის ტიპის კონტროლი.

→ წაიკითხეთ ნაწილი პირველი

ოფიციალური ტიპის მხარდაჭერა (PEP 484)

ჩვენ ჩავატარეთ ჩვენი პირველი სერიოზული ექსპერიმენტები mypy-ით Dropbox-ში 2014 წლის Hack Week-ის განმავლობაში. Hack Week არის ერთკვირიანი ღონისძიება, რომელსაც მასპინძლობს Dropbox. ამ დროის განმავლობაში თანამშრომლებს შეუძლიათ იმუშაონ იმაზე, რაც სურთ! Dropbox-ის ზოგიერთი ყველაზე ცნობილი ტექნოლოგიური პროექტი დაიწყო მსგავსი ღონისძიებებით. ამ ექსპერიმენტის შედეგად დავასკვენით, რომ mypy პერსპექტიულად გამოიყურება, თუმცა პროექტი ჯერ არ არის მზად ფართო გამოყენებისთვის.

იმ დროისთვის პითონის ტიპის მინიშნებით სისტემების სტანდარტიზაციის იდეა იყო ჰაერში. როგორც ვთქვი, Python 3.0-დან შესაძლებელი იყო ტიპის ანოტაციების გამოყენება ფუნქციებისთვის, მაგრამ ეს იყო მხოლოდ თვითნებური გამონათქვამები, განსაზღვრული სინტაქსისა და სემანტიკის გარეშე. პროგრამის შესრულების დროს, ეს ანოტაციები, უმეტესწილად, უბრალოდ იგნორირებული იყო. Hack Week-ის შემდეგ დავიწყეთ სემანტიკის სტანდარტიზაციაზე მუშაობა. ამ სამუშაომ გამოიწვია გაჩენა PEP 484 (გიდო ვან როსუმი, ლუკაშ ლანგა და მე ვთანამშრომლობდით ამ დოკუმენტზე).

ჩვენი მოტივების დანახვა ორი მხრიდან შეიძლებოდა. პირველი, ჩვენ ვიმედოვნებდით, რომ პითონის მთელ ეკოსისტემას შეეძლო მიეღო საერთო მიდგომა ტიპის მინიშნებების გამოყენებისას (ტერმინი გამოიყენება პითონში, როგორც "ტიპის ანოტაციების" ექვივალენტი). ეს, შესაძლო რისკების გათვალისწინებით, უკეთესი იქნება, ვიდრე მრავალი ურთიერთშეთავსებადი მიდგომის გამოყენება. მეორე, გვინდოდა ღიად განგვეხილა ტიპის ანოტაციის მექანიზმები პითონის საზოგადოების ბევრ წევრთან. ეს სურვილი ნაწილობრივ ნაკარნახევი იყო იმით, რომ ჩვენ არ გვინდოდა პითონის პროგრამისტების ფართო მასების თვალში ენის ძირითადი იდეებიდან „განდგომილებად“ დავემსგავსოთ. ეს არის დინამიურად აკრეფილი ენა, რომელიც ცნობილია როგორც "იხვის აკრეფა". საზოგადოებაში, თავიდანვე, სტატიკური აკრეფის იდეის მიმართ გარკვეულწილად საეჭვო დამოკიდებულება არ შეიძლებოდა არ გაჩნდა. მაგრამ ეს გრძნობა საბოლოოდ შემცირდა მას შემდეგ, რაც გაირკვა, რომ სტატიკური აკრეფა არ იქნებოდა სავალდებულო (და მას შემდეგ რაც ხალხი მიხვდა, რომ ის რეალურად სასარგებლო იყო).

ტიპის მინიშნება სინტაქსი, რომელიც საბოლოოდ იქნა მიღებული, ძალიან ჰგავდა იმას, რასაც mypy მხარს უჭერდა იმ დროს. PEP 484 გამოვიდა Python 3.5-ით 2015 წელს. პითონი აღარ იყო დინამიურად აკრეფილი ენა. მე მომწონს ამ მოვლენაზე ფიქრი, როგორც მნიშვნელოვანი ეტაპი პითონის ისტორიაში.

მიგრაციის დაწყება

2015 წლის ბოლოს Dropbox-მა შექმნა სამი ადამიანის გუნდი mypy-ზე სამუშაოდ. მათ შორის იყვნენ გვიდო ვან როსუმი, გრეგ პრაისი და დევიდ ფიშერი. ამ მომენტიდან სიტუაცია ძალიან სწრაფად განვითარდა. პირველი დაბრკოლება mypy-ის ზრდაში იყო შესრულება. როგორც ზემოთ აღვნიშნე, პროექტის პირველ დღეებში ვფიქრობდი mypy იმპლემენტაციის C-ზე თარგმნაზე, მაგრამ ეს იდეა ამ დროისთვის ამოღებულია სიიდან. ჩვენ დავრჩით სისტემის გაშვებით CPython თარჯიმნის გამოყენებით, რომელიც საკმარისად სწრაფი არ არის ისეთი ხელსაწყოებისთვის, როგორიცაა mypy. (არ დაგვეხმარა არც PyPy პროექტი, Python-ის ალტერნატიული განხორციელება JIT შემდგენელთან ერთად.)

საბედნიეროდ, ზოგიერთი ალგორითმული გაუმჯობესება აქ დაგვეხმარა. პირველი ძლიერი "ამაჩქარებელი" იყო დამატებითი შემოწმების განხორციელება. ამ გაუმჯობესების იდეა მარტივი იყო: თუ მოდულის ყველა დამოკიდებულება არ შეცვლილა mypy-ის წინა გაშვების შემდეგ, მაშინ ჩვენ შეგვიძლია გამოვიყენოთ წინა გაშვების დროს ქეშირებული მონაცემები დამოკიდებულებებთან მუშაობისას. დაგვჭირდა მხოლოდ შეცვლილ ფაილებზე და მათზე დამოკიდებულ ფაილებზე ტიპის შემოწმება. Mypy კიდევ უფრო შორს წავიდა: თუ მოდულის გარე ინტერფეისი არ იცვლებოდა, mypy-მ ჩათვალა, რომ სხვა მოდულებს, რომლებმაც შემოიტანეს ეს მოდული, არ სჭირდებოდათ ხელახლა შემოწმება.

დამატებითი შემოწმება ძალიან დაგვეხმარა არსებული კოდების დიდი რაოდენობით ანოტაციისას. საქმე იმაშია, რომ ეს პროცესი ჩვეულებრივ მოიცავს mypy-ის ბევრ განმეორებით გაშვებას, რადგან ანოტაციები თანდათან ემატება კოდს და თანდათან უმჯობესდება. mypy-ის პირველი გაშვება ჯერ კიდევ ძალიან ნელი იყო, რადგან მას ბევრი დამოკიდებულება ჰქონდა შესამოწმებელი. შემდეგ სიტუაციის გასაუმჯობესებლად დავაყენეთ დისტანციური ქეშირების მექანიზმი. თუ mypy აღმოაჩენს, რომ ადგილობრივი ქეში სავარაუდოდ მოძველებულია, ის ჩამოტვირთავს მიმდინარე ქეშის სურათს მთელი კოდების ბაზისთვის ცენტრალიზებული საცავიდან. შემდეგ ის ასრულებს დამატებით შემოწმებას ამ სნეპშოტის გამოყენებით. ამან კიდევ ერთი დიდი ნაბიჯი გადაგვიდგა mypy-ის მუშაობის გაზრდისკენ.

ეს იყო Dropbox-ში ტიპის შემოწმების სწრაფი და ბუნებრივი მიღების პერიოდი. 2016 წლის ბოლოსთვის ჩვენ უკვე გვქონდა პითონის კოდის დაახლოებით 420000 XNUMX სტრიქონი ტიპის ანოტაციებით. ბევრი მომხმარებელი ენთუზიაზმით იყო განწყობილი ტიპის შემოწმებით. უფრო და უფრო მეტი განვითარების გუნდი იყენებდა Dropbox mypy-ს.

მაშინ ყველაფერი კარგად ჩანდა, მაგრამ გასაკეთებელი ჯერ კიდევ ბევრი გვქონდა. ჩვენ დავიწყეთ მომხმარებელთა პერიოდული შიდა გამოკითხვების ჩატარება, რათა განვსაზღვროთ პროექტის პრობლემური სფეროები და გავიგოთ, რა საკითხები უნდა გადაწყდეს პირველ რიგში (ეს პრაქტიკა დღესაც გამოიყენება კომპანიაში). ყველაზე მნიშვნელოვანი, როგორც გაირკვა, ორი დავალება იყო. ჯერ ერთი, გვჭირდებოდა კოდის მეტი ტიპის დაფარვა, მეორეც, გვჭირდებოდა mypy უფრო სწრაფად მუშაობისთვის. სრულიად ცხადი იყო, რომ ჩვენი მუშაობა mypy-ის დაჩქარებაზე და კომპანიის პროექტებში მის განხორციელებაზე ჯერ კიდევ შორს იყო დასრულებამდე. ჩვენ, კარგად გაცნობიერებული ამ ორი ამოცანის მნიშვნელობის შესახებ, შევუდექით მათ გადაჭრას.

მეტი პროდუქტიულობა!

დამატებითი შემოწმებები mypy-ს უფრო აჩქარებდა, მაგრამ ინსტრუმენტი მაინც არ იყო საკმარისად სწრაფი. ბევრი დამატებითი შემოწმება დაახლოებით ერთ წუთს გაგრძელდა. ამის მიზეზი ციკლური იმპორტი იყო. ეს ალბათ არ გააკვირვებს ვინმეს, ვინც მუშაობდა პითონში დაწერილ დიდ კოდების ბაზაზე. ჩვენ გვქონდა ასობით მოდულის ნაკრები, რომელთაგან თითოეული ირიბად შემოიტანა ყველა დანარჩენი. თუ რომელიმე ფაილი იმპორტის მარყუჟში შეიცვლებოდა, mypy-ს უწევდა ამ ციკლის ყველა ფაილის დამუშავება და ხშირად ნებისმიერი მოდული, რომელიც იმპორტირებდა მოდულებს ამ ციკლიდან. ერთ-ერთი ასეთი ციკლი იყო სამარცხვინო „დამოკიდებულების აურზაური“, რომელმაც Dropbox-ში ბევრი უბედურება გამოიწვია. მას შემდეგ, რაც ეს სტრუქტურა შეიცავდა რამდენიმე ასეულ მოდულს, ხოლო იმპორტირებული იყო, პირდაპირ თუ ირიბად, მრავალი ტესტი, იგი ასევე გამოიყენებოდა წარმოების კოდში.

ჩვენ განვიხილეთ წრიული დამოკიდებულებების „გათიშვის“ შესაძლებლობა, მაგრამ ამის რესურსი არ გვქონდა. ძალიან ბევრი კოდი იყო, რომელსაც ჩვენ არ ვიცნობდით. შედეგად მივიღეთ ალტერნატიული მიდგომა. ჩვენ გადავწყვიტეთ, რომ mypy სწრაფად იმუშაოს, თუნდაც "დამოკიდებულების შეფერხების" არსებობის შემთხვევაში. ჩვენ მივაღწიეთ ამ მიზანს mypy დემონის გამოყენებით. დემონი არის სერვერის პროცესი, რომელიც ახორციელებს ორ საინტერესო შესაძლებლობას. პირველ რიგში, ის ინახავს ინფორმაციას მთელი კოდის ბაზის შესახებ მეხსიერებაში. ეს ნიშნავს, რომ ყოველ ჯერზე, როცა აწარმოებთ mypy-ს, თქვენ არ გჭირდებათ ქეშირებული მონაცემების ჩატვირთვა, რომლებიც დაკავშირებულია ათასობით იმპორტირებულ დამოკიდებულებასთან. მეორეც, ის ყურადღებით, მცირე სტრუქტურული ერთეულების დონეზე, აანალიზებს დამოკიდებულებებს ფუნქციებსა და სხვა ერთეულებს შორის. მაგალითად, თუ ფუნქცია foo იძახებს ფუნქციას bar, მაშინ არის დამოკიდებულება foo საწყისი bar. როდესაც ფაილი იცვლება, დემონი ჯერ იზოლირებულად ამუშავებს მხოლოდ შეცვლილ ფაილს. შემდეგ ის უყურებს ამ ფაილის გარედან ხილულ ცვლილებებს, როგორიცაა შეცვლილი ფუნქციის ხელმოწერები. დემონი იყენებს დეტალურ ინფორმაციას იმპორტის შესახებ მხოლოდ იმ ფუნქციების ორჯერ შესამოწმებლად, რომლებიც რეალურად იყენებენ შეცვლილ ფუნქციას. როგორც წესი, ამ მიდგომით, თქვენ უნდა შეამოწმოთ ძალიან ცოტა ფუნქცია.

ამ ყველაფრის განხორციელება ადვილი არ იყო, რადგან ორიგინალური mypy იმპლემენტაცია ფოკუსირებული იყო ერთდროულად ერთი ფაილის დამუშავებაზე. ჩვენ გვქონდა გამკლავება ბევრ სასაზღვრო სიტუაციასთან, რომელთა წარმოშობა მოითხოვდა განმეორებით შემოწმებას იმ შემთხვევებში, როდესაც რაღაც შეიცვალა კოდექსში. მაგალითად, ეს ხდება მაშინ, როდესაც კლასს ენიჭება ახალი საბაზისო კლასი. მას შემდეგ რაც გავაკეთეთ ის, რაც გვინდოდა, ჩვენ შევძელით შემცირებულიყო უმეტესი დამატებითი შემოწმებების შესრულების დრო სულ რამდენიმე წამამდე. ეს ჩვენთვის დიდ გამარჯვებად გვეჩვენებოდა.

კიდევ უფრო მეტი პროდუქტიულობა!

დისტანციურ ქეშირებასთან ერთად, რომელიც ზემოთ განვიხილეთ, mypy დემონმა თითქმის მთლიანად გადაჭრა პრობლემები, რომლებიც წარმოიქმნება, როდესაც პროგრამისტი ხშირად აწარმოებს ტიპის შემოწმებას, ცვლის ფაილების მცირე რაოდენობას. თუმცა, სისტემის მუშაობა ყველაზე ნაკლებად ხელსაყრელი გამოყენების შემთხვევაში ჯერ კიდევ შორს იყო ოპტიმალურისგან. mypy-ის სუფთა გაშვებას შეიძლება 15 წუთზე მეტი დასჭირდეს. და ეს ბევრად მეტი იყო, ვიდრე ჩვენ კმაყოფილი ვიქნებოდით. ყოველ კვირას სიტუაცია უარესდებოდა, რადგან პროგრამისტები განაგრძობდნენ ახალი კოდის დაწერას და არსებულ კოდს ანოტაციების დამატებას. ჩვენს მომხმარებლებს ჯერ კიდევ სწყუროდათ მეტი შესრულება, მაგრამ ჩვენ სიამოვნებით შევხვდით მათ შუა გზაზე.

გადავწყვიტეთ დავუბრუნდეთ ერთ-ერთ ადრინდელ იდეას mypy-სთან დაკავშირებით. კერძოდ, პითონის კოდის C კოდად გადაქცევა. Cython-თან ექსპერიმენტებმა (სისტემა, რომელიც საშუალებას გაძლევთ თარგმნოთ პითონში დაწერილი კოდი C კოდში) არ მოგვცა თვალსაჩინო სიჩქარე, ამიტომ გადავწყვიტეთ გაგვეცოცხლებინა ჩვენი შემდგენელის დაწერის იდეა. ვინაიდან mypy კოდების ბაზა (დაწერილი პითონში) უკვე შეიცავდა ყველა საჭირო ტიპის ანოტაციას, ვფიქრობთ, რომ ღირებული იქნებოდა ამ ანოტაციების გამოყენება სისტემის დასაჩქარებლად. მე სწრაფად შევქმენი პროტოტიპი ამ იდეის შესამოწმებლად. მან აჩვენა მუშაობის 10-ჯერ მეტი ზრდა სხვადასხვა მიკრო ბენჩმარკებზე. ჩვენი იდეა იყო Python-ის მოდულების C მოდულების შედგენა Cython-ის გამოყენებით და ტიპის ანოტაციების გადაქცევა დროის ტიპის შემოწმებებად (ჩვეულებრივ, ტიპის ანოტაციები იგნორირებულია გაშვების დროს და გამოიყენება მხოლოდ ტიპის შემოწმების სისტემებით). ჩვენ რეალურად ვგეგმავდით თარგმნა mypy იმპლემენტაციის Python-დან ენაზე, რომელიც შექმნილია სტატიკურად აკრეფილი, რომელიც გამოიყურებოდა (და, უმეტესწილად, იმუშავებდა) ზუსტად Python-ის მსგავსად. (ამგვარი ენობრივი მიგრაცია mypy პროექტის რაღაც ტრადიციად იქცა. ორიგინალური mypy იმპლემენტაცია დაიწერა Alore-ში, შემდეგ იყო Java-სა და Python-ის სინტაქსური ჰიბრიდი).

CPython-ის გაფართოების API-ზე ფოკუსირება იყო მთავარი იმისთვის, რომ არ დავკარგოთ პროექტის მართვის შესაძლებლობები. ჩვენ არ დაგვჭირდა ვირტუალური მანქანის ან რაიმე ბიბლიოთეკის დანერგვა, რომელიც mypy-ს სჭირდებოდა. გარდა ამისა, ჩვენ კვლავ გვექნებოდა წვდომა პითონის მთელ ეკოსისტემაზე და ყველა ხელსაწყოზე (როგორიცაა pytest). ეს ნიშნავს, რომ ჩვენ შეგვიძლია გავაგრძელოთ ინტერპრეტირებული პითონის კოდის გამოყენება განვითარების დროს, რაც საშუალებას გვაძლევს გავაგრძელოთ მუშაობა კოდის ცვლილებებისა და ტესტირების ძალიან სწრაფი ნიმუშით, ვიდრე კოდის შედგენის მოლოდინში. როგორც ჩანს, ორ სკამზე ჯდომას, ასე ვთქვათ, შესანიშნავ საქმეს ვაკეთებდით და გვიყვარდა.

შემდგენელი, რომელსაც ჩვენ ვუწოდეთ mypyc (რადგან ის იყენებს mypy-ს, როგორც წინა ნაწილს ტიპების ანალიზისთვის), აღმოჩნდა ძალიან წარმატებული პროექტი. საერთო ჯამში, ჩვენ მივაღწიეთ დაახლოებით 4x სიჩქარეს ხშირი mypy გაშვებისთვის ქეშირების გარეშე. mypyc პროექტის ბირთვის შემუშავებას მაიკლ სალივანის, ივან ლევკივსკის, ჰიუ ჰანის და ჩემი პატარა გუნდს დაახლოებით 4 კალენდარული თვე დასჭირდა. სამუშაოს ეს მოცულობა გაცილებით მცირე იყო, ვიდრე საჭირო იქნებოდა mypy-ის გადასაწერად, მაგალითად, C++-ში ან Go-ში. და ჩვენ მოგვიწია პროექტში გაცილებით ნაკლები ცვლილებების შეტანა, ვიდრე უნდა შეგვეტანა სხვა ენაზე გადაწერისას. ჩვენ ასევე ვიმედოვნებდით, რომ შეგვეძლო mypyc-ის ისეთ დონემდე მიყვანა, რომ Dropbox-ის სხვა პროგრამისტებს შეეძლოთ მისი გამოყენება კოდის შედგენისა და დასაჩქარებლად.

შესრულების ამ დონის მისაღწევად, ჩვენ მოგვიწია რამდენიმე საინტერესო საინჟინრო გადაწყვეტის გამოყენება. ამრიგად, შემდგენელს შეუძლია დააჩქაროს მრავალი ოპერაცია სწრაფი, დაბალი დონის C კონსტრუქციების გამოყენებით. მაგალითად, კომპილირებული ფუნქციის გამოძახება ითარგმნება C ფუნქციის გამოძახებად. და ასეთი ზარი ბევრად უფრო სწრაფია, ვიდრე ინტერპრეტირებული ფუნქციის გამოძახება. ზოგიერთი ოპერაციები, როგორიცაა ლექსიკონის ძიება, კვლავ მოიცავდა CPython-ის რეგულარულ C-API ზარებს, რომლებიც მხოლოდ ოდნავ უფრო სწრაფი იყო შედგენისას. ჩვენ მოვახერხეთ ინტერპრეტაციით შექმნილი სისტემაზე დამატებითი დატვირთვის აღმოფხვრა, მაგრამ ეს ამ შემთხვევაში მხოლოდ მცირე მოგებას იძლეოდა შესრულების თვალსაზრისით.

ყველაზე გავრცელებული „ნელი“ ოპერაციების დასადგენად, ჩვენ შევასრულეთ კოდის პროფილირება. ამ მონაცემებით შეიარაღებული, ჩვენ ვცდილობდით შეგვეყენებინა mypyc ისე, რომ მან შექმნას უფრო სწრაფი C კოდი ასეთი ოპერაციებისთვის, ან გადამეწერა შესაბამისი Python კოდი უფრო სწრაფი ოპერაციების გამოყენებით (და ზოგჯერ უბრალოდ არ გვქონდა საკმარისი მარტივი გამოსავალი ამ ან სხვა პრობლემისთვის) . პითონის კოდის ხელახლა ჩაწერა ხშირად პრობლემის უფრო ადვილი გამოსავალი იყო, ვიდრე შემდგენელის მიერ იგივე ტრანსფორმაციის ავტომატურად შესრულება. გრძელვადიან პერსპექტივაში, ჩვენ გვინდოდა ამ ტრანსფორმაციის მრავალი ავტომატიზაცია, მაგრამ იმ დროს ჩვენ ორიენტირებული ვიყავით mypy-ის დაჩქარებაზე მინიმალური ძალისხმევით. და ამ მიზნისკენ სვლისას რამდენიმე კუთხეს ვჭრით.

გაგრძელება იქნება ...

ძვირფასო მკითხველს! როგორი შთაბეჭდილებები გქონდათ mypy პროექტზე, როდესაც შეიტყვეთ მისი არსებობის შესახებ?

წყარო: www.habr.com