Патот до проверка на типот на 4 милиони линии од Python код. Дел 2

Денеска го објавуваме вториот дел од преводот на материјалот за тоа како Dropbox организирал контрола на типот за неколку милиони линии Python код.

→ Прочитајте го првиот дел

Поддршка за официјален тип (PEP 484)

Ги спроведовме нашите први сериозни експерименти со mypy во Dropbox за време на Hack Week 2014 година. Hack Week е еднонеделен настан организиран од Dropbox. За тоа време, вработените можат да работат на што сакаат! Некои од најпознатите технолошки проекти на Dropbox започнаа на настани како овие. Како резултат на овој експеримент, заклучивме дека mypy изгледа ветувачки, иако проектот сè уште не е подготвен за широка употреба.

Во тоа време, идејата за стандардизирање на системите за навестување од типот Пајтон беше во воздухот. Како што реков, од Python 3.0 беше можно да се користат прибелешки за типови за функции, но тоа беа само произволни изрази, без дефинирана синтакса и семантика. За време на извршувањето на програмата, овие прибелешки беа, во најголем дел, едноставно игнорирани. По Hack Week, почнавме да работиме на стандардизирање на семантиката. Оваа работа доведе до појава ПЕП 484 (Гвидо ван Росум, Лукаш Ланга и јас соработувавме на овој документ).

Нашите мотиви можеа да се гледаат од две страни. Прво, се надевавме дека целиот екосистем на Пајтон може да усвои заеднички пристап за користење на навестувања за типови (термин што се користи во Пајтон како еквивалент на „прибелешки на типот“). Ова, со оглед на можните ризици, би било подобро отколку да се користат многу меѓусебно некомпатибилни пристапи. Второ, сакавме отворено да разговараме за механизмите за прибелешки на типот со многу членови на заедницата на Python. Оваа желба беше делумно диктирана од фактот дека не би сакале да изгледаме како „отпадници“ од основните идеи на јазикот во очите на широките маси на програмери на Python. Станува збор за динамички типизиран јазик, познат како „дук typing“. Во заедницата, на самиот почеток, не можеше да не се појави малку сомнителен став кон идејата за статичко пишување. Но, тоа чувство на крајот исчезна откако стана јасно дека статичкото пишување нема да биде задолжително (и откако луѓето сфатија дека тоа е всушност корисно).

Синтаксата на типот навестување што на крајот беше усвоена беше многу слична на она што 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 линии Python код со прибелешки за типови. Многу корисници беа ентузијасти за проверка на типот. Сè повеќе развојни тимови користеа Dropbox mypy.

Сè изгледаше добро тогаш, но имавме уште многу да направиме. Почнавме да спроведуваме периодични интерни анкети на корисници со цел да ги идентификуваме проблематичните области на проектот и да разбереме кои прашања треба да се решат прво (оваа практика сè уште се користи во компанијата денес). Најважни, како што стана јасно, беа две задачи. Прво, ни требаше повеќе покривање на типот на кодот, второ, ни требаше mypy за да работи побрзо. Беше апсолутно јасно дека нашата работа да го забрзаме mypy и да ја имплементираме во проекти на компанијата сè уште беше далеку од завршена. Ние, целосно свесни за важноста на овие две задачи, се зафативме со нивно решавање.

Повеќе продуктивност!

Инкременталните проверки го направија mypy побрз, но алатката сè уште не беше доволно брза. Многу поединечни проверки траеја околу една минута. Причината за тоа беше цикличниот увоз. Ова веројатно нема да го изненади секој кој работел со големи бази на кодови напишани во Python. Имавме комплети од стотици модули, од кои секој индиректно ги увезуваше сите други. Ако било која датотека во увозната јамка била сменета, mypy морал да ги обработи сите датотеки во таа јамка, а често и сите модули што увезувале модули од таа јамка. Еден таков циклус беше озлогласениот „заплет на зависност“ што предизвика многу проблеми во Dropbox. Откако оваа структура содржеше неколку стотици модули, додека беше увезена, директно или индиректно, многу тестови, се користеше и во кодот за производство.

Ја разгледавме можноста за „отплеткување“ на кружните зависности, но немавме ресурси да го направиме тоа. Имаше премногу код со кој не бевме запознаени. Како резултат на тоа, дојдовме до алтернативен пристап. Решивме да направиме mypy да работи брзо дури и во присуство на „заплетки во зависност“. Ја постигнавме оваа цел користејќи го демонот mypy. Демонот е процес на сервер кој имплементира две интересни способности. Прво, складира информации за целата база на кодови во меморијата. Ова значи дека секогаш кога ќе извршите mypy, не мора да вчитувате кеширани податоци поврзани со илјадници увезени зависности. Второ, тој внимателно, на ниво на мали структурни единици, ги анализира зависностите помеѓу функциите и другите ентитети. На пример, ако функцијата foo повикува функција bar, тогаш постои зависност foo од bar. Кога датотеката се менува, демонот прво, изолирано, ја обработува само променетата датотека. Потоа ги разгледува надворешно видливите промени на таа датотека, како што се потписите на променетите функции. Демонот користи детални информации за увозот само за двојно да ги провери оние функции што всушност ја користат изменетата функција. Вообичаено, со овој пристап, треба да проверите многу малку функции.

Спроведувањето на сето ова не беше лесно, бидејќи оригиналната имплементација на mypy беше многу фокусирана на обработка на една датотека во исто време. Моравме да се справиме со многу гранични ситуации, чиешто појавување бараше повторени проверки во случаи кога нешто се смени во кодот. На пример, ова се случува кога на класата и е доделена нова основна класа. Откако го направивме она што го сакавме, можевме да го намалиме времето на извршување на повеќето дополнителни проверки на само неколку секунди. Ова ни изгледаше како голема победа.

Уште поголема продуктивност!

Заедно со далечинското кеширање што го дискутирав погоре, демонот mypy речиси целосно ги реши проблемите што се појавуваат кога програмерот често извршува проверка на типот, правејќи промени на мал број датотеки. Сепак, перформансите на системот во најнеповолниот случај на употреба сè уште беа далеку од оптимални. Чистото стартување на mypy може да потрае повеќе од 15 минути. И ова беше многу повеќе отколку што би биле задоволни. Секоја недела ситуацијата стануваше полоша бидејќи програмерите продолжија да пишуваат нов код и да додаваат прибелешки на постоечкиот код. Нашите корисници сè уште беа гладни за повеќе перформанси, но бевме среќни што ги запознавме на половина пат.

Решивме да се вратиме на една од претходните идеи во врска со mypy. Имено, за конвертирање на Python код во C код. Експериментирањето со Cython (систем кој ви овозможува да го преведете кодот напишан во Python во C код) не ни даде видливо забрзување, па решивме да ја оживееме идејата за пишување наш сопствен компајлер. Бидејќи базата на кодови mypy (напишана во Python) веќе ги содржи сите потребни прибелешки за типот, сметавме дека би било вредно да се обидеме да ги користиме овие прибелешки за да го забрзаме системот. Брзо создадов прототип за да ја тестирам оваа идеја. Покажа повеќе од 10-кратно зголемување на перформансите на различни микро-бенчмаркови. Нашата идеја беше да ги компајлираме модулите на Python во модули C користејќи Cython и да ги претвориме прибелешките за типови во проверки на типот на време на извршување (обично прибелешките за типот се игнорираат при извршување и се користат само од системите за проверка на типот ). Ние, всушност, планиравме да ја преведеме имплементацијата mypy од Python на јазик кој е дизајниран да биде статички пишуван, кој ќе изгледа (и, во најголем дел, ќе функционира) точно како Python. (Овој вид на меѓујазична миграција стана нешто како традиција на проектот mypy. Оригиналната имплементација на mypy беше напишана во Alore, а потоа имаше синтаксички хибрид на Java и Python).

Фокусирањето на API на екстензијата CPython беше клучно за да не се изгубат способностите за управување со проекти. Не ни требаше да имплементираме виртуелна машина или библиотеки што ни беа потребни на mypy. Дополнително, сè уште ќе имаме пристап до целиот екосистем на Python и сите алатки (како што е pytest). Ова значеше дека можеме да продолжиме да го користиме интерпретираниот Python код за време на развојот, овозможувајќи ни да продолжиме да работиме со многу брза шема на правење промени во кодот и негово тестирање, наместо да чекаме кодот да се компајлира. Изгледаше како да правиме одлична работа седејќи на две столчиња, така да се каже, и ни се допадна.

Компајлерот, кој го нарековме mypyc (бидејќи користи mypy како преден дел за анализа на типови), се покажа како многу успешен проект. Севкупно, постигнавме приближно 4x забрзување за чести бегства на mypy без кеширање. За развој на јадрото на проектот mypyc на мал тим од Мајкл Саливан, Иван Левкивски, Хју Хан и јас му беа потребни околу 4 календарски месеци. Овој обем на работа беше многу помал од она што би било потребно за да се препише mypy, на пример, во C++ или Go. И моравме да направиме многу помалку промени во проектот отколку што ќе требаше да направиме кога го препишувавме на друг јазик. Исто така, се надевавме дека ќе го доведеме mypyc на такво ниво што другите програмери на Dropbox би можеле да го користат за да го компајлираат и забрзаат нивниот код.

За да го постигнеме ова ниво на перформанси, моравме да примениме неколку интересни инженерски решенија. Така, компајлерот може да забрза многу операции со користење на брзи конструкции на ниско ниво C. На пример, компајлиран повик на функција се преведува во повик на функција C. И таков повик е многу побрз отколку повикување интерпретирана функција. Некои операции, како што се пребарување на речник, сè уште вклучуваа користење на редовни повици C-API од CPython, кои беа само маргинално побрзи кога се компајлираат. Успеавме да го елиминираме дополнителното оптоварување на системот создадено со толкување, но ова во овој случај даде само мала добивка во однос на перформансите.

За да ги идентификуваме најчестите „бавни“ операции, извршивме профилирање на код. Вооружени со овие податоци, се обидовме или да го прилагодиме mypyc за да генерира побрз C код за такви операции или да го преработиме соодветниот Python-код користејќи побрзи операции (а понекогаш едноставно немавме доволно едноставно решение за тој или друг проблем) . Препишувањето на кодот на Пајтон често беше полесно решение за проблемот отколку компајлерот автоматски да ја изврши истата трансформација. На долг рок, сакавме да автоматизираме многу од овие трансформации, но во тоа време бевме фокусирани на забрзување на mypy со минимален напор. И при движењето кон оваа цел, пресековме неколку агли.

Да се ​​продолжи ...

Почитувани читатели! Какви беа вашите впечатоци од проектот mypy кога дознавте за неговото постоење?

Извор: www.habr.com