Пътят към проверка на типовете на 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 година, вече имахме около 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) се оказа доста успешен проект. В общи линии - постигнахме около 4-кратно ускорение на често стартирания mypy без използване на кеширане. Разработката на ядрото на проекта mypyc от малкия екип, който включваше Майкъл Съливан, Иван Левкивски, Хю Хан и мен, отне около 4 календарни месеца. Обемът на работата беше много по-малък в сравнение с необходимото за преписване на mypy, например, на C++ или на Go. И промените, които трябваше да направим в проекта, бяха много по-малко, отколкото щяха да бъдат, ако го преопишехме на друг език. Освен това се надявахме да можем да развием mypyc до ниво, на което да се използва от други програмисти от Dropbox за компилиране и ускоряване на техния код.

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

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

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

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

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