Пътят към проверка на типовете в 4 милиона реда Python код. Част 2

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

→ Прочетете първата част

Официална поддръжка на типовете (PEP 484)

Проведохме първите сериозни експерименти с mypy в Dropbox по време на Hack Week 2014. Hack Week е събитие, организирано от Dropbox, в което в продължение на една седмица служителите могат да работят по каквото си искат! Някои от най-известните технологични проекти на Dropbox започнаха именно на подобни събития. В резултат на този експеримент установихме, че mypy изглежда многообещаващо, въпреки че проектът все още не е готов за широко използване.

По това време съществуваше идеята за стандартизация на системите за предоставяне на предложения за типовете в Python. Както вече споменах, от Python 3.0 можеше да се използват анотации на типовете за функции, но те бяха просто произволни изрази, без определена синтакса и семантика. По време на изпълнението на програмата, тези анотации по-голямата част просто се игнорираха. След Hack Week започнахме работа по стандартизацията на семантиката. Тази работа доведе до появата на PEP 484 (върху този документ съвместно работеха Гуидо ван Росум, Лукаш Ланга и аз).

Нашите мотиви могат да се разглеждат от две страни. Първо, се надявахме, че цялата екосистема на Python би могла да приеме общ подход за използване на подсказките за типове (type hints — термин, използван в Python като аналог на „анотации на типове“). Това, предвид възможните рискове, щеше да бъде по-добре, отколкото да се използват множество взаимно несъвместими подходи. Второ, искахме открито да обсъдим механизмите за анотиране на типове с много представители на Python общността. Част от това желание произтичаше от желанието ни да не изглеждаме като „отстъпници“ от основните идеи на езика в очите на широките маси Python програмисти. Това е динамично типизиран език, известен с „патицата типизация“. В общността в самото начало не може да не е възникнало леко подозрително отношение към идеята за статична типизация. Но подобно настроение в крайна сметка отслабна — след като стана ясно, че статичната типизация не се планира да стане задължителна (и след като хората осъзнаха, че тя наистина е полезна).

Приетият синтаксис за подкази по типове беше много близък до този, който по онова време поддържаше mypy. Документът PEP 484 беше публикуван заедно с Python 3.5 през 2015 година. Python вече не беше език, който поддържа само динамична типизация. Хубаво ми е да мисля за това събитие като за значима веха в историята на Python.

Започване на миграцията

В края на 2015 година в Dropbox, за работа по mypy, беше създаден екип от трима души. В него влизаха Гвидо ван Россум, Грег Прайс и Дейвид Фишер. От този момент нататък ситуацията започна да се развива изключително бързо. Първата пречка по пътя на растежа на mypy беше производителността. Както вече споменах, в ранния етап на развитие на проекта обмислях да пренеса реализацията на mypy на език C, но тази идея временно беше изключена от списъка. Застанахме на факта, че за стартиране на системата се използваше интерпретаторът CPython, който не се отличаваше с достатъчна скорост за инструменти като mypy. (Проектът PyPy, алтернативна реализация на Python с JIT компилатор, също не ни помогна.)

За щастие, тук ни помогнаха някои алгоритмични подобрения. Първият мощен "ускорител" беше реализирането на инкрементална проверка. Идеята за това подобрение беше проста: ако всички зависимости на модула от последния стартиран mypy не са се променили, можем да използваме, по време на работа с зависимостите, данните, кеширани по време на предишната сесия. Нужно беше само да извършим проверка на типовете в променените файлове и в тези файлове, които зависеха от тях. Mypy отиде дори малко по-далеч: ако външният интерфейс на модула не се е променил — mypy смяташе, че другите модули, които импортират този модул, не трябва да се проверяват отново.

Икономичната проверка значително ни помогна при анотиране на големи обеми съществуващ код. Факт е, че този процес обикновено включва множество итеративни стартирания на mypy, тъй като анотациите се добавят постепенно в кода и го подобряват. Първото стартиране на mypy все още беше много бавно, тъй като при него трябваше да се проверят множество зависимости. Затова, с цел подобряване на ситуацията, реализирахме механизъм за отдалечено кеширане. Ако mypy установи, че локалното кеширане вероятно е остаряло, той зарежда текуща снимка на кеша за цялата кодова база от централизирано хранилище. След това извършва инкрементална проверка, използвайки тази снимка. Това ни придвижи с още една важна крачка напред към увеличаване на производителността на mypy.

Това беше период на бързо и естествено внедряване на системата за проверка на типове в Dropbox. Към края на 2016 г. вече разполагахме с около 420 000 реда Python код с анотации на типове. Много потребителиenthusiастично приеха проверката на типове. В Dropbox mypy беше използван от все повече екипи разработчици.

Всичко изглеждаше добре тогава, но ни оставаше много работа. Започнахме да провеждаме периодични вътрешни анкети сред потребителите, за да открием проблемните области на проекта и да разберем кои въпроси трябва да бъдат решени първо (тази практика се използва и в компанията и днес). Най-важните, както стана ясно, бяха две задачи. Първата - да има повече покритие на кода с типове, втората - да накараме mypy да работи по-бързо. Съвсем ясно беше, че нашата работа по ускоряване на mypy и внедряването му в проектите на компанията все още не е завършена. С напълно осъзнато значение на тези две задачи, се захванахме с тяхното решаване.

Повече производителност!

Инкрементните проверки ускориха mypy, но този инструмент все още не беше достатъчно бърз. Много инкрементни проверки отнемаха около минута. Причината за това бяха цикличните импорти. Това вероятно няма да изненада никого, работил с големи кодови бази, написани на Python. Имахме набори от стотици модули, всеки от които косвено импортируваше останалите. Ако някой файл в цикъла на импортите беше променен, mypy трябваше да обработи всички файлове, които влизат в този цикъл, а често и всякакви модули, които импортират модули от този цикъл. Един от тези цикли беше печално известният „възел на зависимостите“, който доведе до множество неприятности в Dropbox. Веднъж тази структура съдържаше няколко стотин модули, като множеството тестове я импортираха, пряко или косвено, и тя се използваше и в продакшън кода.

Ние обмисляхме възможността за „разплитане“ на цикличните зависимости, но нямахме ресурси за това. Имаше твърде много код, с който не бяхме запознати. В крайна сметка прибегнахме до алтернативен подход. Решихме да направим така, че mypy да работи бързо дори при наличие на „възли на зависимостите“. Достигахме тази цел с помощта на демона mypy. Демонът е сървърен процес, който реализира две интересни възможности. Първо — той държи в паметта информация за цялата кодова база. Това означава, че при всеки стартиране на mypy не е необходимо да се зареждат кешираните данни, свързани с хиляди импортнати зависимости. Второ — той внимателно, на нивото на малки структурни единици, анализира зависимостите между функциите и другите субекти. Например, ако функцията Трябва ли да пишем цяла роля за всеки модул? Или по-добре е да имаме голяма роля за всичко? А ако не е роля, то къде да пишем — в pre или в post? извиква функцията bar, то има зависимост Трябва ли да пишем цяла роля за всеки модул? Или по-добре е да имаме голяма роля за всичко? А ако не е роля, то къде да пишем — в pre или в post? от bar. Когато файлът бъде променен — демонът първо, в изолация, обработва само променения файл. След това той разглежда промените в този файл, видими навън, като променените сигнатури на функциите. Демонът използва детайлна информация за импортите само за повторно проверяване на тези функции, които наистина използват променената функция. Обикновено при такъв подход се налага да се проверяват много малко функции.

Реализация всичко това не беше лесна работа, тъй като първоначалната реализация на mypy беше силно насочена към обработка на един файл в даден момент. Трябваше да се сблъскаме с много гранични ситуации, при които възникваха необходимост от повторни проверки, когато в кода нещо се променеше. Например, това се случва, когато на клас бъде назначен нов основен клас. След като направихме желаните промени, успяхме да намалим времето за изпълнение на повечето инкрементални проверки до няколко секунди. За нас това беше голяма победа.

Още повече производителност!

Вместо дистанционно кеширане, за което говорих по-горе, демонът mypy практически напълно реши проблемите, които възникваха, когато програмист често стартира проверка на типовете, правейки промени в малък брой файлове. Въпреки това, производителността на системата в най-неблагоприятния сценарий все още далеч не беше оптимална. Чистото стартиране на mypy можеше да отнеме повече от 15 минути. А това беше доста повече, отколкото бихме желали. С всяка изминала седмица ситуацията ставаше все по-лоша, тъй като програмистите продължаваха да пишат нов код и да добавят анотации към съществуващия код. Нашите потребители все още жадуваха за по-висока производителност и ние с удоволствие бяхме готови да им се отзовем.

Решихме да се върнем към една от ранните идеи свързани с mypy. А именно – преобразуването на Python код в C код. Експериментите с Cython (система, която позволява транслация на код написан на Python в C код) не ни донесоха видимо ускорение, затова решихме да възродим идеята за написване на собствен компилатор. Тъй като кодовата база на mypy (написана на Python) вече съдържаше всички необходими типови анотации, ни се стори, че е достойно да опитаме да използваме тези анотации за ускоряване на работата на системата. Бързо създадох прототип за проверка на тази идея. Той показа повече от десеткратно увеличение на производителността при различни микро-бенчмаркове. Идеята ни беше да компилираме Python модули в C модули със средствата на Cython и да превръщаме типови анотации в проверки на типове, извършвани по време на изпълнението на програмата (обикновено типови анотации се игнорират по време на изпълнение на програмите и се използват само от системите за проверка на типове). Всъщност, планирахме да пренесем реализацията на mypy от Python на език, който е статично типизиран, и който би изглеждал (и в по-голямата си част работил) точно като Python. (Този вид междужанрова миграция стана нещо като традиция за проекта mypy. Първоначалната реализация на mypy беше написана на Alore, след това беше създаден синтактичен хибрид между Java и Python).

Ориентацията към API на разширенията на CPython беше ключова, за да не загубим възможности за управление на проекта. Необходимо беше да реализираме виртуална машина или каквито и да било библиотеки, от които mypy имаше нужда. Освен това, все още щяхме да имаме достъп до цялата екосистема на Python и всички инструменти (като pytest). Това означаваше, че можем да продължим да използваме интерпретируемия Python код по време на разработката, което ни позволяваше да продължим да работим с много бърза схема за корекции на кода и тестване, а не да чакаме компилацията на кода. Изглеждаше така, сякаш успяваме да седим на два стола, и това ни харесваше.

Компилаторът, който нарекохме mypyc (тъй като използва mypy за анализ на типовете), се оказа доста успешен проект. Общо взето, постигнахме около 4-кратно ускорение на чести стартирания на mypy без използване на кеширане. Разработката на ядрото на проекта mypyc отне на малкия екип, в който бяхме Майкъл Съливан, Иван Левкивски, Хю Хан и аз, около 4 календарни месеца. Този обем работа беше значително по-малък от необходимия за пренаписване на mypy, например, на C++ или Go. Освен това, промените в проекта, които трябваше да направим, бяха много по-малко, отколкото ако го пренаписвахме на друг език. Надявахме се дори, че ще успеем да доведем mypyc до такова ниво, че и други програмисти от Dropbox да могат да го използват за компилиране и ускоряване на своя код.

За да постигнем такова ниво на производителност, трябваше да приложим някои интересни инженерни решения. Например, компилаторът може да ускори изпълнението на много операции благодарение на използването на бързи нискоуровни конструкции на C. Например, извикването на компилирана функция се трансформира в извикване на C-функция. Такова извикване се изпълнява много по-бързо от извикването на интерпретирана функция. Някои операции, като търсене в речници, все още се свеждаха до използване на стандартни извиквания на C-API от CPython, които след компилация се оказваха само малко по-бързи. Успяхме да се отървем от допълнителната натовареност на системата, произтичаща от интерпретацията, но в този случай това доведе само до малко подобрение в производителността.

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

Продължението следва…

Уважаеми читатели! Какви впечатления Ви остави проектът mypy, когато научихте за неговото съществуване?

Източник: habr.com